I have succesfully built xynth on an Arm9 platform but I seem to have some problems running the demos. Most often they exits with and segmentation fault when moving the mouse around the screen or clicking some button. It seems to originate from peculiar memory problem. Below is two example traces from gdb.
Has anybody had similar problems on a arm9 crosscompile before?
Heres a gdb backtrace from when "load" crashes:
---------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x40195518 in malloc () from /lib/libc.so.0
(gdb) bt
#0 0x40195518 in malloc () from /lib/libc.so.0
#1 0x40029230 in s_malloc (size=880) at alloc.c:22
#2 0x400292a8 in s_calloc (nmemb=1, size=880) at alloc.c:32
#3 0x40030904 in s_event_init (event=0xbeab3b60) at event.c:281
#4 0x400307a4 in s_event_copy (event=0x153e8, nevent=0xbeab3b7c)
at event.c:255
#5 0x40030888 in s_event_changed (window=0x15100) at event.c:270
#6 0x4003ee00 in s_socket_listen_expose (window=0x15100, soc=6)
at socket.c:347
#7 0x4003f11c in s_socket_listen_parse (window=0x15100, soc=6)
at socket.c:411
#8 0x4003f80c in s_socket_in_f (window=0x15100, pfd=0x152c8) at socket.c:549
#9 0x4003f5ac in s_socket_listen_wait (window=0x15100, timeout=1000)
at socket.c:505
#10 0x40043038 in s_window_loop (arg=0x15100) at window.c:269
#11 0x400430cc in s_window_main (arg=0x15100) at window.c:285
#12 0x0000b494 in main (argc=1, argv=0xbeab3d84) at load.c:559
And a similar crash of "child"
---------------------------------------------
Program received signal SIGABRT, Aborted.
0x401998e4 in kill () from /lib/libc.so.0
(gdb) bt
#0 0x401998e4 in kill () from /lib/libc.so.0
#1 0x40193610 in abort () from /lib/libc.so.0
#2 0x40195fbc in __malloc_consolidate () from /lib/libc.so.0
#3 0x40195230 in malloc () from /lib/libc.so.0
#4 0x40029230 in s_malloc (size=880) at alloc.c:22
#5 0x400292a8 in s_calloc (nmemb=1, size=880) at alloc.c:32
#6 0x40030904 in s_event_init (event=0xbe9c7b4c) at event.c:281
#7 0x400307a4 in s_event_copy (event=0x123e8, nevent=0xbe9c7b68)
at event.c:255
#8 0x40030888 in s_event_changed (window=0x12100) at event.c:270
#9 0x4003ee00 in s_socket_listen_expose (window=0x12100, soc=6)
at socket.c:347
#10 0x4003f11c in s_socket_listen_parse (window=0x12100, soc=6)
at socket.c:411
#11 0x4003f80c in s_socket_in_f (window=0x12100, pfd=0x122c8) at socket.c:549
#12 0x4003f5ac in s_socket_listen_wait (window=0x12100, timeout=-1)
at socket.c:505
#13 0x40043038 in s_window_loop (arg=0x12100) at window.c:269
#14 0x400430cc in s_window_main (arg=0x12100) at window.c:285
#15 0x00009820 in main (argc=1, argv=0xbe9c7d84) at child.c:195
regards
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i did not see any crosstool error like this before :|
if helps, i have listed the toolchains i am using on ti davinci platform which is arm926ej-s (armv5te-j). xynth works on ti davinci, which is arm926ej-s with below cross toolchains successfully.
- gcc-3.4.6 - glibc-2.3.6 prepared with crosstool (abi soft float)
- gcc-4.2.3 - glibc-2.5.1 from Sourcery Cross Toolchain version arm2008q1 (eabi)
- gcc-4.2.4 - glibc-2.7 prepared with crosstool-ng (eabi aapcs)
alper.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Im not using glibc but instead uclibc 0.9.27, could this cause problems? I saw a patch guarded by __UCLIBC__ in the xynth sources but this was only referring to some pthread stuff.
regards
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
forgot: moving the mouse around the screen when an application is running causes a whole bunch of tiny memory allocations through malloc which doesn't seem to be freed again, but it is not a out-of-memory problem as there is always memory available when it crashes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
running with valgind --leak-check=yes --show-reachable=yes output shows that, there is no errors, and no leaks in demo applications. (output pasted below).
and with glibc on arm9 i do not see that kind of problems, so i think that that might be somehow related to the uclibc, or maybe gcc it self you are using.
can you share the toolchain you are using right now, so that i can try it here on arm9 boards i have.
alper.
[valgrind output]
# valgrind --leak-check=yes --show-reachable=yes child
==2877== Memcheck, a memory error detector.
==2877== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==2877== Using LibVEX rev 1804, a library for dynamic binary translation.
==2877== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==2877== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==2877== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==2877== For more details, rerun with: -v
==2877==
[0x0428DCE0] CLIENT :: Connected to server via UDS (/tmp/.Xynth/UDS-0) [s_socket_init_uds (socket.c:635)]
[0x0428DCE0] CLIENT :: [-1] Requesting 0x00000007 (SOC_DATA_DISPLAY) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Requesting 0x00000001 (SOC_DATA_NEW) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Requesting 0x00000009 (SOC_DATA_CONFIGURE) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Requesting 0x00000009 (SOC_DATA_CONFIGURE) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Requesting 0x00000002 (SOC_DATA_SHOW) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_listen_parse (socket.c:441)]
[0x04F6FB90] CLIENT :: [0] Requesting 0x00000008 (SOC_DATA_FORMDRAW) from server [s_socket_request (socket.c:245)]
[0x04F6FB90] CLIENT :: [0] gained focus [child_atevent (child.c:27)]
[0x04F6FB90] CLIENT :: [0] Requesting 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_listen_parse (socket.c:441)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000005 (SOC_DATA_EVENT) from server [s_socket_listen_parse (socket.c:441)]
...
...
...
[0x0428DCE0] CLIENT :: [0] Received 0x00000005 (SOC_DATA_EVENT) from server [s_socket_listen_parse (socket.c:441)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_listen_parse (socket.c:441)]
[0x04F6FB90] CLIENT :: [0] Requesting 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000005 (SOC_DATA_EVENT) from server [s_socket_listen_parse (socket.c:441)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000003 (SOC_DATA_CLOSE) from server [s_socket_listen_parse (socket.c:441)]
[0x0428DCE0] CLIENT :: [0] Exiting (WINDOW_TYPE_MAIN) [s_window_uninit (window.c:195)]
==2877==
==2877== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==2877== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2877== malloc/free: 5,452 allocs, 5,452 frees, 1,435,352 bytes allocated.
==2877== For counts of detected errors, rerun with: -v
==2877== All heap blocks were freed -- no leaks are possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have now succesfully built xynth with a glibc based toolchain and its stable, so it must be some problem related to the version of uclibc I am using.
Thanks for your help Alper, and thanks for a great looking windowing system.
regards
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have succesfully built xynth on an Arm9 platform but I seem to have some problems running the demos. Most often they exits with and segmentation fault when moving the mouse around the screen or clicking some button. It seems to originate from peculiar memory problem. Below is two example traces from gdb.
Has anybody had similar problems on a arm9 crosscompile before?
Heres a gdb backtrace from when "load" crashes:
---------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x40195518 in malloc () from /lib/libc.so.0
(gdb) bt
#0 0x40195518 in malloc () from /lib/libc.so.0
#1 0x40029230 in s_malloc (size=880) at alloc.c:22
#2 0x400292a8 in s_calloc (nmemb=1, size=880) at alloc.c:32
#3 0x40030904 in s_event_init (event=0xbeab3b60) at event.c:281
#4 0x400307a4 in s_event_copy (event=0x153e8, nevent=0xbeab3b7c)
at event.c:255
#5 0x40030888 in s_event_changed (window=0x15100) at event.c:270
#6 0x4003ee00 in s_socket_listen_expose (window=0x15100, soc=6)
at socket.c:347
#7 0x4003f11c in s_socket_listen_parse (window=0x15100, soc=6)
at socket.c:411
#8 0x4003f80c in s_socket_in_f (window=0x15100, pfd=0x152c8) at socket.c:549
#9 0x4003f5ac in s_socket_listen_wait (window=0x15100, timeout=1000)
at socket.c:505
#10 0x40043038 in s_window_loop (arg=0x15100) at window.c:269
#11 0x400430cc in s_window_main (arg=0x15100) at window.c:285
#12 0x0000b494 in main (argc=1, argv=0xbeab3d84) at load.c:559
And a similar crash of "child"
---------------------------------------------
Program received signal SIGABRT, Aborted.
0x401998e4 in kill () from /lib/libc.so.0
(gdb) bt
#0 0x401998e4 in kill () from /lib/libc.so.0
#1 0x40193610 in abort () from /lib/libc.so.0
#2 0x40195fbc in __malloc_consolidate () from /lib/libc.so.0
#3 0x40195230 in malloc () from /lib/libc.so.0
#4 0x40029230 in s_malloc (size=880) at alloc.c:22
#5 0x400292a8 in s_calloc (nmemb=1, size=880) at alloc.c:32
#6 0x40030904 in s_event_init (event=0xbe9c7b4c) at event.c:281
#7 0x400307a4 in s_event_copy (event=0x123e8, nevent=0xbe9c7b68)
at event.c:255
#8 0x40030888 in s_event_changed (window=0x12100) at event.c:270
#9 0x4003ee00 in s_socket_listen_expose (window=0x12100, soc=6)
at socket.c:347
#10 0x4003f11c in s_socket_listen_parse (window=0x12100, soc=6)
at socket.c:411
#11 0x4003f80c in s_socket_in_f (window=0x12100, pfd=0x122c8) at socket.c:549
#12 0x4003f5ac in s_socket_listen_wait (window=0x12100, timeout=-1)
at socket.c:505
#13 0x40043038 in s_window_loop (arg=0x12100) at window.c:269
#14 0x400430cc in s_window_main (arg=0x12100) at window.c:285
#15 0x00009820 in main (argc=1, argv=0xbe9c7d84) at child.c:195
regards
Martin
hi,
i did not see any crosstool error like this before :|
if helps, i have listed the toolchains i am using on ti davinci platform which is arm926ej-s (armv5te-j). xynth works on ti davinci, which is arm926ej-s with below cross toolchains successfully.
- gcc-3.4.6 - glibc-2.3.6 prepared with crosstool (abi soft float)
- gcc-4.2.3 - glibc-2.5.1 from Sourcery Cross Toolchain version arm2008q1 (eabi)
- gcc-4.2.4 - glibc-2.7 prepared with crosstool-ng (eabi aapcs)
alper.
Thanks for replying alper.
Im not using glibc but instead uclibc 0.9.27, could this cause problems? I saw a patch guarded by __UCLIBC__ in the xynth sources but this was only referring to some pthread stuff.
regards
Martin
hi,
that is only for pthread attribute stuff, somehow uclibc does not like attribute settings so i did disabled them for uclibc. nothing really important.
alper.
forgot: moving the mouse around the screen when an application is running causes a whole bunch of tiny memory allocations through malloc which doesn't seem to be freed again, but it is not a out-of-memory problem as there is always memory available when it crashes.
hi,
running with valgind --leak-check=yes --show-reachable=yes output shows that, there is no errors, and no leaks in demo applications. (output pasted below).
and with glibc on arm9 i do not see that kind of problems, so i think that that might be somehow related to the uclibc, or maybe gcc it self you are using.
can you share the toolchain you are using right now, so that i can try it here on arm9 boards i have.
alper.
[valgrind output]
# valgrind --leak-check=yes --show-reachable=yes child
==2877== Memcheck, a memory error detector.
==2877== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==2877== Using LibVEX rev 1804, a library for dynamic binary translation.
==2877== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==2877== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==2877== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==2877== For more details, rerun with: -v
==2877==
[0x0428DCE0] CLIENT :: Connected to server via UDS (/tmp/.Xynth/UDS-0) [s_socket_init_uds (socket.c:635)]
[0x0428DCE0] CLIENT :: [-1] Requesting 0x00000007 (SOC_DATA_DISPLAY) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Requesting 0x00000001 (SOC_DATA_NEW) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Requesting 0x00000009 (SOC_DATA_CONFIGURE) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Requesting 0x00000009 (SOC_DATA_CONFIGURE) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Requesting 0x00000002 (SOC_DATA_SHOW) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_listen_parse (socket.c:441)]
[0x04F6FB90] CLIENT :: [0] Requesting 0x00000008 (SOC_DATA_FORMDRAW) from server [s_socket_request (socket.c:245)]
[0x04F6FB90] CLIENT :: [0] gained focus [child_atevent (child.c:27)]
[0x04F6FB90] CLIENT :: [0] Requesting 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_listen_parse (socket.c:441)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000005 (SOC_DATA_EVENT) from server [s_socket_listen_parse (socket.c:441)]
...
...
...
[0x0428DCE0] CLIENT :: [0] Received 0x00000005 (SOC_DATA_EVENT) from server [s_socket_listen_parse (socket.c:441)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_listen_parse (socket.c:441)]
[0x04F6FB90] CLIENT :: [0] Requesting 0x00000006 (SOC_DATA_EXPOSE) from server [s_socket_request (socket.c:245)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000005 (SOC_DATA_EVENT) from server [s_socket_listen_parse (socket.c:441)]
[0x0428DCE0] CLIENT :: [0] Received 0x00000003 (SOC_DATA_CLOSE) from server [s_socket_listen_parse (socket.c:441)]
[0x0428DCE0] CLIENT :: [0] Exiting (WINDOW_TYPE_MAIN) [s_window_uninit (window.c:195)]
==2877==
==2877== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==2877== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2877== malloc/free: 5,452 allocs, 5,452 frees, 1,435,352 bytes allocated.
==2877== For counts of detected errors, rerun with: -v
==2877== All heap blocks were freed -- no leaks are possible.
I have now succesfully built xynth with a glibc based toolchain and its stable, so it must be some problem related to the version of uclibc I am using.
Thanks for your help Alper, and thanks for a great looking windowing system.
regards
Martin