Thread: [Tuxpaint-devel] Kaleidoscope crash
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Bill K. <nb...@so...> - 2007-11-29 15:50:13
|
Someone reported a bug about Tux Paint crashing (on an RPM-based platform, FWIW) when using the new Kaleidoscope tool: https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 Anyone seen this? :( -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: Caroline F. <car...@go...> - 2007-11-29 16:14:48
|
On Thu, 2007-11-29 at 07:50 -0800, Bill Kendrick wrote: > Someone reported a bug about Tux Paint crashing (on an RPM-based platform, > FWIW) when using the new Kaleidoscope tool: > > https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 > > Anyone seen this? :( > No but I'll see if I can reproduce. On Ubuntu bug trackers we normally ask for back traces etc. Is there a point in doing so here? I've no idea how debug version of packages are put together etc. Caroline |
From: Bill K. <nb...@so...> - 2007-11-29 16:57:36
|
On Thu, Nov 29, 2007 at 04:20:25PM +0000, Caroline Ford wrote: > On Ubuntu bug trackers we normally ask for back traces etc. Is there a > point in doing so here? I've no idea how debug version of packages are > put together etc. A backtrace was actually included (as an attachment). :) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: Albert C. <aca...@gm...> - 2007-11-30 04:24:31
|
Running tuxpaint under valgrind, I got this: ==1937== Conditional jump or move depends on uninitialised value(s) ==1937== at 0x406B17B: (within /usr/lib/libSDL-1.2.so.0.11.1) ==1937== by 0x406BB09: (within /usr/lib/libSDL-1.2.so.0.11.1) ==1937== by 0x4037EF6: SDL_PumpEvents (in /usr/lib/libSDL-1.2.so.0.11.1) ==1937== by 0x4038406: SDL_PollEvent (in /usr/lib/libSDL-1.2.so.0.11.1) ==1937== by 0x804D7ED: mySDL_PollEvent (in /home/olpc/tuxpaint/tuxpaint) I guess I didn't have debug info in the build. Doing this on the XO hardware is really hard because the CPU is slow. Anyway, mySDL_PollEvent has a problem. |
From: Pere P. i C. <pe...@fo...> - 2007-11-30 23:13:05
|
El dj 29 de 11 del 2007 a les 07:50 -0800, en/na Bill Kendrick va escriure: > Someone reported a bug about Tux Paint crashing (on an RPM-based platform, > FWIW) when using the new Kaleidoscope tool: > > https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 > > Anyone seen this? :( > Running with sound works fine, but without sound: tuxpaint --nosound --600x480 ==555== Conditional jump or move depends on uninitialised value(s) ==555== at 0x4084868: (within /usr/lib/libSDL-1.2.so.0.11.1) ==555== by 0x4084FD0: (within /usr/lib/libSDL-1.2.so.0.11.1) ==555== by 0x40539D6: SDL_PumpEvents (in /usr/lib/libSDL-1.2.so.0.11.1) ==555== by 0x4053EE6: SDL_PollEvent (in /usr/lib/libSDL-1.2.so.0.11.1) ==555== by 0x804E317: mySDL_PollEvent (tuxpaint.c:16045) ==555== by 0x80698D3: main (tuxpaint.c:1556) ==555== ==555== Invalid read of size 4 ==555== at 0x412C834: Mix_HaltChannel (in /usr/lib/libSDL_mixer-1.2.so.0.2.6) ==555== by 0x8054821: magic_stopsound (tuxpaint.c:17184) ==555== by 0x745EC79: kalidescope_release (in /usr/local/lib/tuxpaint/plugins/kalidescope.so) ==555== by 0x806355E: mainloop (tuxpaint.c:3619) ==555== by 0x8068EC6: main (tuxpaint.c:1779) ==555== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==555== ==555== Process terminating with default action of signal 11 (SIGSEGV) ==555== Access not within mapped region at address 0x4 ==555== at 0x412C834: Mix_HaltChannel (in /usr/lib/libSDL_mixer-1.2.so.0.2.6) ==555== by 0x8054821: magic_stopsound (tuxpaint.c:17184) ==555== by 0x745EC79: kalidescope_release (in /usr/local/lib/tuxpaint/plugins/kalidescope.so) ==555== by 0x806355E: mainloop (tuxpaint.c:3619) ==555== by 0x8068EC6: main (tuxpaint.c:1779) ==555== ==555== ERROR SUMMARY: 203 errors from 23 contexts (suppressed: 414 from 1) ==555== malloc/free: in use at exit: 17,043,315 bytes in 15,374 blocks. ==555== malloc/free: 260,609 allocs, 245,235 frees, 122,713,957 bytes allocated. ==555== For counts of detected errors, rerun with: -v ==555== searching for pointers to 15,374 not-freed blocks. ==555== checked 26,319,088 bytes. ==555== ==555== |
From: Pere P. i C. <pe...@fo...> - 2007-11-30 23:43:11
|
El ds 01 de 12 del 2007 a les 00:14 +0100, en/na Pere Pujal i Carabantes va escriure: > El dj 29 de 11 del 2007 a les 07:50 -0800, en/na Bill Kendrick va > escriure: > > Someone reported a bug about Tux Paint crashing (on an RPM-based platform, > > FWIW) when using the new Kaleidoscope tool: > > > > https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 > > > > Anyone seen this? :( > > > Running with sound works fine, but without sound: BTW magic displace crashes as well without sound. |
From: Pere P. i C. <pe...@fo...> - 2007-12-01 10:28:19
|
El ds 01 de 12 del 2007 a les 00:44 +0100, en/na Pere Pujal i Carabantes va escriure: > El ds 01 de 12 del 2007 a les 00:14 +0100, en/na Pere Pujal i Carabantes > va escriure: > > El dj 29 de 11 del 2007 a les 07:50 -0800, en/na Bill Kendrick va > > escriure: > > > Someone reported a bug about Tux Paint crashing (on an RPM-based platform, > > > FWIW) when using the new Kaleidoscope tool: > > > > > > https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 > > > > > > Anyone seen this? :( > > > > > Running with sound works fine, but without sound: > > BTW magic displace crashes as well without sound. > Comenting out the call to api->stopsound(); Kaleidoscope tool don't crash, so maybe the problem is in this call. I guess Shift will do the same. Hope this helps Pere |
From: Caroline F. <car...@go...> - 2007-11-30 23:56:29
|
On 30/11/2007, Pere Pujal i Carabantes <pe...@fo...> wrote: > > El ds 01 de 12 del 2007 a les 00:14 +0100, en/na Pere Pujal i Carabantes > va escriure: > > El dj 29 de 11 del 2007 a les 07:50 -0800, en/na Bill Kendrick va > > escriure: > > > Someone reported a bug about Tux Paint crashing (on an RPM-based platform, > > > FWIW) when using the new Kaleidoscope tool: > > > > > > https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 > > > > > > Anyone seen this? :( > > > > > Running with sound works fine, but without sound: > > BTW magic displace crashes as well without sound. > Running on Ubuntu gutsy without sound I get a crash with the kaleidoscope tool when I clicked on a new colour. I have the following from valgrind: Process terminating with default action of signal 11 (SIGSEGV) ==19239== Access not within mapped region at address 0x4 ==19239== at 0x40F3630: Mix_HaltChannel (mixer.c:829) ==19239== by 0x80597F9: magic_stopsound (in /usr/local/bin/tuxpaint) ==19239== by 0x7E39D19: kalidescope_release (in /usr/local/lib/tuxpaint/plugins/kalidescope.so) ==19239== by 0x8065B3C: main (in /usr/local/bin/tuxpaint) I have the full trace I can send as I've no real clue on how to read valgrind traces. Caroline |
From: Caroline F. <car...@go...> - 2007-12-01 00:06:28
Attachments:
gdb-tuxpaint.txt
|
On 30/11/2007, Caroline Ford <car...@go...> wrote: > On 30/11/2007, Pere Pujal i Carabantes <pe...@fo...> wrote: > > > > El ds 01 de 12 del 2007 a les 00:14 +0100, en/na Pere Pujal i Carabantes > > va escriure: > > > El dj 29 de 11 del 2007 a les 07:50 -0800, en/na Bill Kendrick va > > > escriure: > > > > Someone reported a bug about Tux Paint crashing (on an RPM-based platform, > > > > FWIW) when using the new Kaleidoscope tool: > > > > > > > > https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 > > > > > > > > Anyone seen this? :( > > > > > > > Running with sound works fine, but without sound: > > > > BTW magic displace crashes as well without sound. > > > > Running on Ubuntu gutsy without sound I get a crash with the > kaleidoscope tool when I clicked on a new colour. > > I have the following from valgrind: > > Process terminating with default action of signal 11 (SIGSEGV) > ==19239== Access not within mapped region at address 0x4 > ==19239== at 0x40F3630: Mix_HaltChannel (mixer.c:829) > ==19239== by 0x80597F9: magic_stopsound (in /usr/local/bin/tuxpaint) > ==19239== by 0x7E39D19: kalidescope_release (in > /usr/local/lib/tuxpaint/plugins/kalidescope.so) > ==19239== by 0x8065B3C: main (in /usr/local/bin/tuxpaint) > > I have the full trace I can send as I've no real clue on how to read > valgrind traces. > > Caroline > Run the same under gdb. It crashed at the same point. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1222666560 (LWP 19326)] 0xb7e02630 in Mix_HaltChannel (which=0) at mixer.c:829 829 mixer.c: No such file or directory. in mixer.c I've attached the trace but I don't know how to get debug symbols on tuxpaint, but I have installed debug symbols in all sdl etc. Caroline |
From: Caroline F. <car...@go...> - 2007-12-01 00:13:45
Attachments:
gdb-tuxpaint2.txt
|
On 30/11/2007, Pere Pujal i Carabantes <pe...@fo...> wrote: > > El ds 01 de 12 del 2007 a les 00:14 +0100, en/na Pere Pujal i Carabantes > va escriure: > > El dj 29 de 11 del 2007 a les 07:50 -0800, en/na Bill Kendrick va > > escriure: > > > Someone reported a bug about Tux Paint crashing (on an RPM-based platform, > > > FWIW) when using the new Kaleidoscope tool: > > > > > > https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 > > > > > > Anyone seen this? :( > > > > > Running with sound works fine, but without sound: > > BTW magic displace crashes as well without sound. I can verify that the "shift tool" behaves the same way,. I was allowed to move the image once. The second time I tried I got Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1222854976 (LWP 19431)] 0xb7dd4630 in Mix_HaltChannel (which=0) at mixer.c:829 829 mixer.c: No such file or directory. in mixer.c (gdb) Trace attacjhed. again it's Ubuntu Gutsy. Caroline |
From: Caroline F. <car...@go...> - 2007-12-01 00:51:16
Attachments:
gdb-tuxpaint3.txt
|
On 01/12/2007, Caroline Ford <car...@go...> wrote: > On 30/11/2007, Pere Pujal i Carabantes <pe...@fo...> wrote: > > > > El ds 01 de 12 del 2007 a les 00:14 +0100, en/na Pere Pujal i Carabantes > > va escriure: > > > El dj 29 de 11 del 2007 a les 07:50 -0800, en/na Bill Kendrick va > > > escriure: > > > > Someone reported a bug about Tux Paint crashing (on an RPM-based platform, > > > > FWIW) when using the new Kaleidoscope tool: > > > > > > > > https://sourceforge.net/tracker/?func=detail&atid=516295&aid=1840828&group_id=66938 > > > > > > > > Anyone seen this? :( > > > > > > > Running with sound works fine, but without sound: > > > > BTW magic displace crashes as well without sound. > > I can verify that the "shift tool" behaves the same way,. I was > allowed to move the image once. The second time I tried I got > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1222854976 (LWP 19431)] > 0xb7dd4630 in Mix_HaltChannel (which=0) at mixer.c:829 > 829 mixer.c: No such file or directory. > in mixer.c > (gdb) > > Trace attacjhed. again it's Ubuntu Gutsy. > > Caroline I've got something that might be a bit better. I uninstalled tuxpaint and rebuilt with make debug=yes. I then did sudo make install debug=yes This gave me some more info which I've captured using gdb. I don't think I have symbols for the magic tool though. New trace attached. Caroline > > |
From: Albert C. <aca...@gm...> - 2007-12-01 02:10:09
|
If using gdb, then use Electric Fence at the same time. Without that, the crash is likely to be in unrelated code. The bad code overflows a buffer, but this doesn't cause an immediate crash. Later, good code calls malloc() and gets a crash because malloc() walks a corrupt list. Electric Fence puts unmapped memory after each allocation, causing crashes to be immediate and making gdb useful. You can: a. link with -lefence b. set LD_PRELOAD to the name of the libefence *.so c. use the "ef" program, which sets LD_PRELOAD for you See "man efence" for extra info; setting the alignment to 0 would be a good idea. There are many things this won't spot though. Valgrind is probably the better tool. |
From: Caroline F. <car...@go...> - 2007-12-01 02:27:10
|
On 01/12/2007, Albert Cahalan <aca...@gm...> wrote: > If using gdb, then use Electric Fence at the same time. > Without that, the crash is likely to be in unrelated code. > The bad code overflows a buffer, but this doesn't cause > an immediate crash. Later, good code calls malloc() > and gets a crash because malloc() walks a corrupt list. > Electric Fence puts unmapped memory after each allocation, > causing crashes to be immediate and making gdb useful. > > You can: > > a. link with -lefence > b. set LD_PRELOAD to the name of the libefence *.so > c. use the "ef" program, which sets LD_PRELOAD for you > > See "man efence" for extra info; setting the alignment > to 0 would be a good idea. > > There are many things this won't spot though. Valgrind > is probably the better tool. > I was using the standard Ubuntu program crash rules. We ask them for a backtrace https://wiki.ubuntu.com/Backtrace using gbd and then using Valgrind https://wiki.ubuntu.com/Valgrind My concern is that I can't get a debug version of tuxpaint. I'm guessing I'd need to hack on the makefiles. |
From: Albert C. <aca...@gm...> - 2007-12-01 04:55:16
|
On Nov 30, 2007 9:27 PM, Caroline Ford <car...@go...> wrote: > I was using the standard Ubuntu program crash rules. We ask them for a > backtrace https://wiki.ubuntu.com/Backtrace using gbd and then using > Valgrind https://wiki.ubuntu.com/Valgrind As long as you use valgrind, you'll cover the problem. The misleading results from gdb could cause developers to waste time though, so getting the Ubuntu crash rules adjusted would still be a good idea. > My concern is that I can't get a debug version of tuxpaint. I'm > guessing I'd need to hack on the makefiles. Variables can be overridden on the command line. Do this: make OPTFLAGS="-Os -g3" I'm using this right now, since I need to build without Pango and SVG, and since I'm building for the Geode processor: LANG=C make NOPANGOFLAG=NO_SDLPANGO SDL_PANGO_LIB= SVG_LIB= SVG_CFLAGS= NOSVGFLAG=NOSVG OPTFLAGS='-g3 -O2 -fno-tree-pre -march=geode -mtune=geode -mpreferred-stack-boundary=2 -mmmx -m3dnow -fomit-frame-pointer -falign-functions=0 -falign-jumps=0 -DOLPC_XO -DSUGAR' |
From: Bill K. <nb...@so...> - 2007-12-01 20:46:28
|
Ack! Ok, so last minute I added a Magic plugin API to stop sounds. The sounds you provided for Shift and Kaleidoscope were good, but if you stopped clicking/dragging at certain points, they'd go on a bit too long. So I had them stop upon mouse release. But if sound is disabled, it crashes because the sound system isn't on, and I FORGOT TO CHECK. :^Z I guess 0.9.19 will come Real Soon Now. In the meantime, I at least have a work-around (don't use without sound :) ) Thanks for investigating, folks! -bill! On Sat, Dec 01, 2007 at 12:06:27AM +0000, Caroline Ford wrote: > > Running on Ubuntu gutsy without sound I get a crash with the > > kaleidoscope tool when I clicked on a new colour. > > > > Run the same under gdb. It crashed at the same point. > -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: Caroline F. <car...@go...> - 2007-12-02 17:36:54
|
I wondered as they were just on the two that I made sounds for.. I guess I should make a sound for calligraphy very quickly ;) Caroline On Sat, 2007-12-01 at 12:46 -0800, Bill Kendrick wrote: > Ack! Ok, so last minute I added a Magic plugin API to stop sounds. > The sounds you provided for Shift and Kaleidoscope were good, but if > you stopped clicking/dragging at certain points, they'd go on a bit too > long. So I had them stop upon mouse release. But if sound is disabled, > it crashes because the sound system isn't on, and I FORGOT TO CHECK. :^Z > > I guess 0.9.19 will come Real Soon Now. In the meantime, I at least have > a work-around (don't use without sound :) ) > > Thanks for investigating, folks! > > -bill! > > On Sat, Dec 01, 2007 at 12:06:27AM +0000, Caroline Ford wrote: > > > Running on Ubuntu gutsy without sound I get a crash with the > > > kaleidoscope tool when I clicked on a new colour. > > > > > > > Run the same under gdb. It crashed at the same point. > > > |
From: Bill K. <nb...@so...> - 2007-12-04 17:40:29
|
On Thu, Nov 29, 2007 at 11:24:35PM -0500, Albert Cahalan wrote: > Running tuxpaint under valgrind, I got this: > > ==1937== Conditional jump or move depends on uninitialised value(s) > ==1937== at 0x406B17B: (within /usr/lib/libSDL-1.2.so.0.11.1) > ==1937== by 0x406BB09: (within /usr/lib/libSDL-1.2.so.0.11.1) > ==1937== by 0x4037EF6: SDL_PumpEvents (in /usr/lib/libSDL-1.2.so.0.11.1) > ==1937== by 0x4038406: SDL_PollEvent (in /usr/lib/libSDL-1.2.so.0.11.1) > ==1937== by 0x804D7ED: mySDL_PollEvent (in /home/olpc/tuxpaint/tuxpaint) > > I guess I didn't have debug info in the build. Doing this > on the XO hardware is really hard because the CPU is slow. > Anyway, mySDL_PollEvent has a problem. I don't think it was really a problem, just valgrind pointing out that I had sent a pointer to an uninitialized "SDL_Event" struct... which was fine, because mySDL_PollEvent() would fill it in. Anyway, this one is moot, because I've given up on the idea of record/playback in Tux Paint (for demo purposes). I think it's easy enough to create a video ('screencast') and if folks out there demoing Tux Paint want to have an automated demo, they can do it using a video, rather than having Tux Paint 'play by itself.' -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: Albert C. <aca...@gm...> - 2007-12-04 17:58:29
|
On Dec 4, 2007 12:40 PM, Bill Kendrick <nb...@so...> wrote: > On Thu, Nov 29, 2007 at 11:24:35PM -0500, Albert Cahalan wrote: > > ==1937== Conditional jump or move depends on uninitialised value(s) > > ==1937== at 0x406B17B: (within /usr/lib/libSDL-1.2.so.0.11.1) > > ==1937== by 0x406BB09: (within /usr/lib/libSDL-1.2.so.0.11.1) > > ==1937== by 0x4037EF6: SDL_PumpEvents (in /usr/lib/libSDL-1.2.so.0.11.1) > > ==1937== by 0x4038406: SDL_PollEvent (in /usr/lib/libSDL-1.2.so.0.11.1) > > ==1937== by 0x804D7ED: mySDL_PollEvent (in /home/olpc/tuxpaint/tuxpaint) > > > > I guess I didn't have debug info in the build. Doing this > > on the XO hardware is really hard because the CPU is slow. > > Anyway, mySDL_PollEvent has a problem. > > I don't think it was really a problem, just valgrind pointing out that I had > sent a pointer to an uninitialized "SDL_Event" struct... which was fine, > because mySDL_PollEvent() would fill it in. Nope, valgrind isn't that stupid. Read the message again. The code is making a decision based on uninitialized data. Pardon me if you're secretly an x86 expert and this is obvious... The x86 has instructions similar to "if(x) goto y" in C. It also has "if(x) y=z" instructions. Valgrind detected that one of these was executed with "x" uninitialized. These instructions generally come quite directly from the high-level conditional tests in C. That includes the "for" loop termination condition, the ?: operator, etc. Remember that valgrind has a low-level view of things. Valgrind tolerates copies of uninitialized data, allowing you to memcpy a partly-initialized struct. This also means that you can have dummy arguments to functions. No alarm is raised until the code makes a decision based on the data or passes the data into a system call for something like disk IO. Thus I'm fairly sure there is a real and serious problem. > Anyway, this one is moot, because I've given up on the idea of record/playback > in Tux Paint (for demo purposes). I think it's easy enough to create a > video ('screencast') and if folks out there demoing Tux Paint want to have > an automated demo, they can do it using a video, rather than having Tux Paint > 'play by itself.' I always saw that as way more useful for automated testing. It would be great to have Tux Paint test itself. It could run through all the plug-ins, etc. Of course, if nobody actually makes and runs a test script, then the feature just isn't getting used. |
From: Bill K. <nb...@so...> - 2007-12-04 20:10:21
|
On Tue, Dec 04, 2007 at 12:58:28PM -0500, Albert Cahalan wrote: > Nope, valgrind isn't that stupid. Read the message again. > The code is making a decision based on uninitialized data. > > Pardon me if you're secretly an x86 expert and this is obvious... On the contrary, this is all new territory for me, sadly. :) -bill! |