nanogui: Thread: valgrind log

All,

When i'm runnig my app with valgrind i get following traces.


==22052== Syscall param write(buf) points to uninitialised byte(s)
==22052==    at 0x499093: __write_nocancel (in /lib/libpthread-2.3.5.so)
==22052==    by 0x1B930874: nxFlushReq (nxproto.c:179)
==22052==    by 0x1B92C9D9: ReadBlock (client.c:146)
==22052==    by 0x1B92CAA0: CheckBlockType (client.c:229)
==22052==    by 0x1B92FE9F: GrLoadImageFromFile (client.c:267)
==22052==    by 0x805C5E6: CImage::LoadFromFile(std::string, int, 
int) (Image.cpp:81)
==22052==    by 0x8062F22: CConfig::PreLoadImages() (Config.cpp:134)
==22052==    by 0x80626EF: CConfig::CConfig() (Config.cpp:51)
==22052==    by 0x804A3A0: CWindowManager::init(ICS_NAME_DSCR*) 
(WindowManager.cpp:90)
==22052==    by 0x804D438: main (VgaUi.cpp:147)
==22052==  Address 0x1B975572 is 82 bytes inside a block of size 2048 alloc'd
==22052==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==22052==    by 0x1B930842: nxFlushReq (nxproto.c:62)
==22052==    by 0x1B9308F9: nxAllocReq (nxproto.c:45)
==22052==    by 0x1B92E785: GrSetPortraitMode (client.c:4351)
==22052==    by 0x804D314: main (VgaUi.cpp:77)


Can anyone tell me what todo with it cuz i'm not following this 
completely and i really want to know whats going on here and whats 
causing it...

Thanks

-=Michael=-

When using threads, you must set THREADSAFE=Y in the
config file.  This could be the cause of bad write() data below.
The function nxFlushReq is called to flush a buffer of
nano-X client commands queued up to send to the server.
For speed, these aren't sent until a call requiring a server
read (like GrGetNextEvent or GrGetWindowInfo) is called,
or GrFlush() is called.  Then, the queued data is sent.

Seems to me you might be having multiple threads unprotectingly
call GrXXX functions at the same time...

Regards,

Greg


: ==22052== Syscall param write(buf) points to uninitialised byte(s)
: ==22052==    at 0x499093: __write_nocancel (in /lib/libpthread-2.3.5.so)
: ==22052==    by 0x1B930874: nxFlushReq (nxproto.c:179)
: ==22052==    by 0x1B92C9D9: ReadBlock (client.c:146)
: ==22052==    by 0x1B92CAA0: CheckBlockType (client.c:229)
: ==22052==    by 0x1B92FE9F: GrLoadImageFromFile (client.c:267)
: ==22052==    by 0x805C5E6: CImage::LoadFromFile(std::string, int,
: int) (Image.cpp:81)
: ==22052==    by 0x8062F22: CConfig::PreLoadImages() (Config.cpp:134)
: ==22052==    by 0x80626EF: CConfig::CConfig() (Config.cpp:51)
: ==22052==    by 0x804A3A0: CWindowManager::init(ICS_NAME_DSCR*)
: (WindowManager.cpp:90)
: ==22052==    by 0x804D438: main (VgaUi.cpp:147)
: ==22052==  Address 0x1B975572 is 82 bytes inside a block of size 2048
alloc'd
: ==22052==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
: ==22052==    by 0x1B930842: nxFlushReq (nxproto.c:62)
: ==22052==    by 0x1B9308F9: nxAllocReq (nxproto.c:45)
: ==22052==    by 0x1B92E785: GrSetPortraitMode (client.c:4351)
: ==22052==    by 0x804D314: main (VgaUi.cpp:77)

Greg,

My Application has no threads at all!? Could there be any other 
causes for this!?

Regards

-=Michael=-


At 02:30 10/03/2006, Greg Haerr wrote:
>When using threads, you must set THREADSAFE=Y in the
>config file.  This could be the cause of bad write() data below.
>The function nxFlushReq is called to flush a buffer of
>nano-X client commands queued up to send to the server.
>For speed, these aren't sent until a call requiring a server
>read (like GrGetNextEvent or GrGetWindowInfo) is called,
>or GrFlush() is called.  Then, the queued data is sent.
>
>Seems to me you might be having multiple threads unprotectingly
>call GrXXX functions at the same time...
>
>Regards,
>
>Greg
>
>
>: ==22052== Syscall param write(buf) points to uninitialised byte(s)
>: ==22052==    at 0x499093: __write_nocancel (in /lib/libpthread-2.3.5.so)
>: ==22052==    by 0x1B930874: nxFlushReq (nxproto.c:179)
>: ==22052==    by 0x1B92C9D9: ReadBlock (client.c:146)
>: ==22052==    by 0x1B92CAA0: CheckBlockType (client.c:229)
>: ==22052==    by 0x1B92FE9F: GrLoadImageFromFile (client.c:267)
>: ==22052==    by 0x805C5E6: CImage::LoadFromFile(std::string, int,
>: int) (Image.cpp:81)
>: ==22052==    by 0x8062F22: CConfig::PreLoadImages() (Config.cpp:134)
>: ==22052==    by 0x80626EF: CConfig::CConfig() (Config.cpp:51)
>: ==22052==    by 0x804A3A0: CWindowManager::init(ICS_NAME_DSCR*)
>: (WindowManager.cpp:90)
>: ==22052==    by 0x804D438: main (VgaUi.cpp:147)
>: ==22052==  Address 0x1B975572 is 82 bytes inside a block of size 2048
>alloc'd
>: ==22052==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
>: ==22052==    by 0x1B930842: nxFlushReq (nxproto.c:62)
>: ==22052==    by 0x1B9308F9: nxAllocReq (nxproto.c:45)
>: ==22052==    by 0x1B92E785: GrSetPortraitMode (client.c:4351)
>: ==22052==    by 0x804D314: main (VgaUi.cpp:77)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####

: My Application has no threads at all!? Could there be any other
: causes for this!?

Well - is your program operating correctly?  If so, then this is likely
just the nano-X buffer not being filled in completely, as is the
case for some junk bytes in the nxproto.h header file.

Regards,

Greg



: >: ==22052== Syscall param write(buf) points to uninitialised byte(s)
: >: ==22052==    at 0x499093: __write_nocancel (in
/lib/libpthread-2.3.5.so)

At the moment it seems to be working fine yes.

the only outcome of the valgrind in the previously posted .

As for the rest my application is working as a spear.

ps: Is it possible to add a cleanup function to clear the remaining resources

Thnx

-=Mihael=-



At 17:43 13/03/2006, Greg Haerr wrote:
>: My Application has no threads at all!? Could there be any other
>: causes for this!?
>
>Well - is your program operating correctly?  If so, then this is likely
>just the nano-X buffer not being filled in completely, as is the
>case for some junk bytes in the nxproto.h header file.
>
>Regards,
>
>Greg
>
>
>
>: >: ==22052== Syscall param write(buf) points to uninitialised byte(s)
>: >: ==22052==    at 0x499093: __write_nocancel (in
>/lib/libpthread-2.3.5.so)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####

: ps: Is it possible to add a cleanup function to clear the remaining
resources

Yes, go right ahead.

Regards,

Greg

At 19:50 14/03/2006, Greg Haerr wrote:
>: ps: Is it possible to add a cleanup function to clear the remaining
>resources
>
>Yes, go right ahead.

i'd really like to, when i have some time left .... :-)

anyone any suggestion on how to speed up the nanox... running on an arm 60mhz


>Regards,
>
>Greg

: >: ps: Is it possible to add a cleanup function to clear the remaining
: >resources
: i'd really like to, when i have some time left .... :-)

I'm not aware of any resources not being cleaned up, that's why
I suggested you do it.  Please advise of which resources you're talking
about.


:
: anyone any suggestion on how to speed up the nanox... running on an arm
60mhz

We need specific issues here.  Which drawing functions are you finding
bottlenecks in?  What other speed issues are you having?  What
is your hw display format?

I assume you've turned off the debugging asserts found in include/device.h
and drivers/fblin*.c.

Regards,

Greg

At 17:30 15/03/2006, Greg Haerr wrote:
>: >: ps: Is it possible to add a cleanup function to clear the remaining
>: >resources
>: i'd really like to, when i have some time left .... :-)
>
>I'm not aware of any resources not being cleaned up, that's why
>I suggested you do it.  Please advise of which resources you're talking
>about.
Never mind this request. shame on me... some stupid bug in my app


>:
>: anyone any suggestion on how to speed up the nanox... running on an arm
>60mhz
>
>We need specific issues here.  Which drawing functions are you finding
>bottlenecks in?  What other speed issues are you having?  What
>is your hw display format?

In general i'm using bitmaps to draw all my windows in combination 
with text and some rect's.
Its just that the time that is required to draw a screen is taking a 
long time. but maybe this is due to
the limits of the cpu.
The problem is mostly the time to load the bitmaps.
I'm using a 640 by 480 256 color display.

I use offscreen pix map to draw on and then copy it to the onscreen 
window... i presume this is the fastest way to do it



>I assume you've turned off the debugging asserts found in include/device.h
>and drivers/fblin*.c.

have to checl tis. did not yet look at it


>Regards,
>
>Greg
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####

On Mon, Mar 20, 2006 at 09:17:55AM +0100, Michael Bogaerts wrote:
> In general i'm using bitmaps to draw all my windows in combination 
> with text and some rect's.
> Its just that the time that is required to draw a screen is taking a 
> long time. but maybe this is due to
> the limits of the cpu.
> The problem is mostly the time to load the bitmaps.
> I'm using a 640 by 480 256 color display.
> 
> I use offscreen pix map to draw on and then copy it to the onscreen 
> window... i presume this is the fastest way to do it

spend some time to optimize your blit routines.  I am not familiar with
ARM, but if there is a block copy available (or possibly even DMA) it
would be put to good use here.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####