tuxpaint-devel

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

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

[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