tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Ubuntu bugs on tuxpaint

[Caroline F. <car...@go...>]

On Sat, 2007-12-08 at 15:15 -0500, Albert Cahalan wrote:
> On Dec 8, 2007 4:40 AM, Caroline Ford <car...@go...> wrote:
> 
> > I've submitted one bug to our bug tracker - a crash bug with backtraces.
> 
> It's not terribly helpful. It shows the obvious
> signature of heap corruption, a crash in _int_malloc.
> The bad code could be anywhere; your stack trace
> does not point to the bad code. It is misleading.
> 
> To catch an overflow when it happens, right as
> it is corrupting the heap data structures, you need
> either valgrind or electric fence. Valgrind works all
> by itself. Electric fence needs to be used with gdb.

Well this is the info Ubuntu collects from its crash logs and the back
traces it generates. 

I don't know what to suggest - this is the information they are giving
us. Their debugging procedures and bug triaging procedures use gdb,
their automatic crash dump process (apport) does the same I think.

It's not *my* bug so I can't get any more info..

Caroline

Re: [Tuxpaint-devel] Ubuntu bugs on tuxpaint

[Sascha S. <sas...@si...>]

On Sat, Dec 08, 2007 at 03:15:10PM -0500, Albert Cahalan wrote:

> To catch an overflow when it happens, right as
> it is corrupting the heap data structures, you need
> either valgrind or electric fence.
At least on glibc-based systems, setting MALLOC_CHECK_=3D2 can be quite=20
useful, too, and doesn't require anything special to be installed.

CU Sascha

--=20
http://sascha.silbe.org/
http://www.infra-silbe.de/

Re: [Tuxpaint-devel] Ubuntu bugs on tuxpaint

[Albert C. <aca...@gm...>]

On Dec 8, 2007 4:40 AM, Caroline Ford <car...@go...> wrote:

> I've submitted one bug to our bug tracker - a crash bug with backtraces.

It's not terribly helpful. It shows the obvious
signature of heap corruption, a crash in _int_malloc.
The bad code could be anywhere; your stack trace
does not point to the bad code. It is misleading.

To catch an overflow when it happens, right as
it is corrupting the heap data structures, you need
either valgrind or electric fence. Valgrind works all
by itself. Electric fence needs to be used with gdb.

[Tuxpaint-devel] Ubuntu bugs on tuxpaint

[Caroline F. <car...@go...>]

I've gone through the bugs filed on Ubuntu that refer to tuxpaint. There
are thankfully very few of them :)

https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=tuxpaint&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=

I've submitted one bug to our bug tracker - a crash bug with backtraces.

There is a bug requesting the packaging of 0.9.18 - Debian seem not to
have packaged it yet so Ubuntu haven't got it. I've told them to wait
until 0.9.19.

I'm presuming that there are two bugs stopping 0.9.19 - the kaleidoscope
bug, and the fonts >127 bug. Even though I think we've fixed the first I
presume the latter would cause enough problems for their end users that
they should stick with 0.9.17 rather than use a CVS version.

I've also set myself to be emailed whenever an Ubuntu bug is filed
against tuxpaint or any of the bits - -stamps, -config etc.

Caroline

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Tamil not Unicode (was re: bugs)

[Karl O. H. <ka...@hu...>]

Tysdag 4. desember 2007 skreiv Bill Kendrick:

>Problems include:
>
>=A0 * This is the only font we have for Tamil right now
>=A0 * The PO file for Tamil is written such that it works with this font
>=A0 =A0 (i.e., it's not 'written' using Unicode Tamil characters.)

This last problem is easy enough to correct, e.g., by using
http://billposer.org/Software/tamilconverters.html

=2D-=20
Karl Ove Hufthammer

Re: [Tuxpaint-devel] Started porting tuxpaint to new NOKIA N810 internet tablet

[Alessandro P. <apa...@gm...>]

2007/12/7, Bill Kendrick <nb...@so...>:
> On Thu, Dec 06, 2007 at 11:40:55AM +0100, Alessandro Pasotti wrote:
> > Hi,
> >
> > I started working on tp again.
> >
> > I'm trying to port tp to the new tablet, since it has a keyboard, the
> > text tool can now be enabled.
> >
> > I suggest to create a new make target nokia810 and a new MAEMOFLAG=NOKIA_810.
> >
> > All changes will go into
> > #if defined(NOKIA_810)
> >
> > May I proceed?
> >
> > I will document changes in changelog.
>
> Certainly.  I just committed some BeOS changes for 'Begasus'.
> I forget, you have CVS access, right?

Yes, I believe I still have commit rights.

>
> Thx & good luck!
>
> -bill!
> PS - I'd like to add an on-screen keyboard to Tux Paint at some point.
> That'll be some localization fun. ;)


That would be fun indeed :)

I would like to add a config option to enlarge the editing window
avoiding to show the message area, do you think is it feasible?

Does such an option already exists?



-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] Started porting tuxpaint to new NOKIA N810 internet tablet

[Bill K. <nb...@so...>]

On Thu, Dec 06, 2007 at 11:40:55AM +0100, Alessandro Pasotti wrote:
> Hi,
> 
> I started working on tp again.
> 
> I'm trying to port tp to the new tablet, since it has a keyboard, the
> text tool can now be enabled.
> 
> I suggest to create a new make target nokia810 and a new MAEMOFLAG=NOKIA_810.
> 
> All changes will go into
> #if defined(NOKIA_810)
> 
> May I proceed?
> 
> I will document changes in changelog.

Certainly.  I just committed some BeOS changes for 'Begasus'.
I forget, you have CVS access, right?

Thx & good luck!

-bill!
PS - I'd like to add an on-screen keyboard to Tux Paint at some point.
That'll be some localization fun. ;)

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

[Tuxpaint-devel] Started porting tuxpaint to new NOKIA N810 internet tablet

[Alessandro P. <apa...@gm...>]

Hi,

I started working on tp again.

I'm trying to port tp to the new tablet, since it has a keyboard, the
text tool can now be enabled.

I suggest to create a new make target nokia810 and a new MAEMOFLAG=NOKIA_810.

All changes will go into
#if defined(NOKIA_810)

May I proceed?

I will document changes in changelog.

-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] Kaleidoscope crash

[Bill K. <nb...@so...>]

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!

Re: [Tuxpaint-devel] Kaleidoscope crash

[Albert C. <aca...@gm...>]

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.

Re: [Tuxpaint-devel] Kaleidoscope crash

[Bill K. <nb...@so...>]

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/

Re: [Tuxpaint-devel] SDL-pango (was bugs)

[Bill K. <nb...@so...>]

On Fri, Nov 30, 2007 at 10:55:20PM +0000, Caroline Ford wrote:
> make nopango produces more errors:
> 
> secret@eser:/media/feisty/home/secret/Music/tuxpaint-0.9.18$ make
> nopango
> 
> Building with Pango DISABLED
> 
> make NOPANGOFLAG=NO_SDLPANGO SDL_PANGO_LIB=
> make[1]: Entering directory
> `/media/feisty/home/secret/Music/tuxpaint-0.9.18'
> 
> ...Linking Tux Paint...
> obj/tuxpaint.o: In function `wordwrap_text_ex':tuxpaint.c:(.text
> +0x3e39): undefined reference to `SDLPango_SetDefaultColor'
<snip>

I'm not seeing this. :^/

Additionally, I discovered that building w/o sound support wasn't
working.  I've corrected it, and just build (on Ubuntu 7.10 Gutsy Gibbon)
minimal Tux Paint...

  $ make SVG_LIB= SVG_CFLAGS= NOSVGFLAG=NOSVG \
      NOPANGOFLAG=NO_SDLPANGO SDL_PANGO_LIB= \
      SDL_MIXER_LIB= NOSOUNDFLAG=NOSOUND

And here's the what it's linked against (output of "ldd ./tuxpaint"):

        linux-gate.so.1 =>  (0xffffe000)
        libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7e4d000)
        libSDL_image-1.2.so.0 => /usr/lib/libSDL_image-1.2.so.0 (0xb7e32000)
        libSDL_ttf-2.0.so.0 => /usr/lib/libSDL_ttf-2.0.so.0 (0xb7e2c000)
        libpaper.so.1 => /usr/lib/libpaper.so.1 (0xb7e29000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e04000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7cba000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7c97000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0xb7bd1000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7bcc000)
        libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb7b75000)
        libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb7b6f000)
        libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb7b60000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7b48000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7b32000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7ac2000)
        /lib/ld-linux.so.2 (0xb7ef3000)

-bill!

Re: [Tuxpaint-devel] bugs

[Bill K. <nb...@so...>]

On Fri, Nov 30, 2007 at 10:37:21PM +0000, Caroline Ford wrote:
> Ah - I though it was added in 0.9.17.. (now this makes sense..)
> 
> Dapper (and Edgy) don't have any of the SDL-pango packages. I've
> downloaded and compiled SDL_Pango but it's still not happy complaining
> with:
<snip>

So until someone decides it's worth backporting the latest Pango and SDL_Pango
to Edgy and Dapper, builds for those version of Ubuntu will need Pango support
disabled, I guess.  Sorry :(

(Similar to what Shin-Ichi did for Fedora CORE 4 and earlier, and
what John will be doing for Windows 95/98/ME.)

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

[Tuxpaint-devel] Tamil not Unicode (was re: bugs)

[Bill K. <nb...@so...>]

On Thu, Nov 29, 2007 at 12:54:27PM -0500, Albert Cahalan wrote:
> 
> I doubt that font is even good for Tamil.
> 
> Fonts are supposed to have Unicode tables.
> The OS is supposed to let you type in Unicode.
> One should be able to mix Tamil with ASCII.
> 
> If that font is used on a modern system, do you
> just get rectangular boxes when you type Tamil?
> Typing ASCII to get Tamil is wrong. You should type
> Tamil if you want Tamil.
> 
> Fontforge can be used to recode the font.

Problems include:

  * This is the only font we have for Tamil right now
  * The PO file for Tamil is written such that it works with this font
    (i.e., it's not 'written' using Unicode Tamil characters.)

We need to find someone knowledgable in Tamil to correct both of these
issues.

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] passing -128 to malloc considered harmful

[Bill K. <nb...@so...>]

On Fri, Nov 30, 2007 at 01:10:45AM -0500, Albert Cahalan wrote:
> ==981== Warning: silly arg (-128) to malloc()

I'm no good at reading valgrind output.  Any idea _where_ in the app this
is happening?  Is it happening all the time?  Perhaps we can gdb and set
breakpoints on all malloc() calls to find out...

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] tuxpaint crash: read past a 141056-byte malloc

[Bill K. <nb...@so...>]

On Fri, Nov 30, 2007 at 12:13:59AM -0500, Albert Cahalan wrote:
> ==1937== Thread 1:
> ==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)
> ==1937==
> ==1937== Invalid read of size 8
> ==1937==    at 0x40639FD: (within /usr/lib/libSDL-1.2.so.0.11.1)
> ==1937==    by 0xE7: ???
> ==1937==  Address 0x97B8E60 is 8 bytes after a block of size 141,056 alloc'd
> ==1937==    at 0x40224E5: malloc (vg_replace_malloc.c:149)
> ==1937==    by 0x405BC83: SDL_CreateRGBSurface (in
> /usr/lib/libSDL-1.2.so.0.11.1)
> ==1937==    by 0x804E62A: thumbnail2 (in /home/olpc/tuxpaint/tuxpaint)
> ==1937==
> ==1937== Invalid read of size 8
> ==1937==    at 0x4063A04: (within /usr/lib/libSDL-1.2.so.0.11.1)
> ==1937==    by 0xE7: ???
> ==1937==  Address 0x97B8E58 is 0 bytes after a block of size 141,056 alloc'd
> ==1937==    at 0x40224E5: malloc (vg_replace_malloc.c:149)
> ==1937==    by 0x405BC83: SDL_CreateRGBSurface (in
> /usr/lib/libSDL-1.2.so.0.11.1)
> ==1937==    by 0x804E62A: thumbnail2 (in /home/olpc/tuxpaint/tuxpaint)
> 
> My screen size is 1200x900, 2 bytes per pixel.
> This is 32-bit x86 with MMX enabled.

So if I'm reading this right, thumbnail2 is reading past where it should.

What options are you building with?

  NO_BILINEAR
  LOW_QUALITY_THUMBNAILS

getpixel/putpixel should be making sure we don't read/write beyond the
surface, so I'm not yet sure what's going on here.

Have you investigated any more since?  Thx!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Kaleidoscope crash

[Caroline F. <car...@go...>]

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.
> > 
> 

Re: [Tuxpaint-devel] Kaleidoscope crash

[Bill K. <nb...@so...>]

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/

Re: [Tuxpaint-devel] Kaleidoscope crash

[Pere P. i C. <pe...@fo...>]

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

Re: [Tuxpaint-devel] Kaleidoscope crash

[Albert C. <aca...@gm...>]

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'

Re: [Tuxpaint-devel] Kaleidoscope crash

[Caroline F. <car...@go...>]

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.

Re: [Tuxpaint-devel] Kaleidoscope crash

[Albert C. <aca...@gm...>]

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.

Re: [Tuxpaint-devel] Kaleidoscope crash

[Caroline F. <car...@go...>]

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
>
>

Re: [Tuxpaint-devel] Kaleidoscope crash

[Caroline F. <car...@go...>]

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

Re: [Tuxpaint-devel] Kaleidoscope crash

[Caroline F. <car...@go...>]

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