[ppc] eworkpanel hangs with memory leak when menu is clicked

[konsolefreak]

On my iBook G4, I compiled and installed ede.  I can't click on the button with my name on the taskbar.  If  I do, eworkpanel locks up, and after a minutes the vmsize was 200MB nad growing.  According to GDB is was stalled in some eFLTK XML function.

[vljubovic]

Logged In: YES 
user_id=110776

Sadly, we can't obtain a G4 to test this problem. efltk 
contains a number of bugs (e.g. 64bit platforms) which we 
simply don't have the manpower to fix. This is why EDE 2.0 
will be based on fltk2 (for details see www.fltk.org). 
This is also a great task so we would appreciate your help 
and feedback. Details on how to get involved will be 
published soon. 
 
Thank you for reporting. 

[konsolefreak]

Logged In: YES 
user_id=1502924

I think it does this on any big endian machine.

[karijes]

Logged In: YES 
user_id=832040

Can you please obtain gdb output? This content would be much
apreciated.

Sanel

[konsolefreak]

Logged In: YES 
user_id=1502924

I'm in gdb right now and I really don't what I need to do.  I don't think efltk or ede was compiled with -g but I don't know how to take advantage of that if it were.

(gdb) run
Starting program: /usr/local/bin/eworkpanel 
System Image Format: 16 bits per pixel
Display Visual: 16 bits per pixel
System Image byte-order: Big-endian

Program received signal SIGINT, Interrupt.
0x0fee7ae0 in Fl_XmlTokenizer::eos () from /usr/local/lib/libefltk_xml.so.2.0
(gdb) next
Single stepping until exit from function _ZNK15Fl_XmlTokenizer3eosEv, 
which has no line number information.
0x0fee8db4 in Fl_XmlTokenizer::read_next ()
   from /usr/local/lib/libefltk_xml.so.2.0
(gdb) next
Single stepping until exit from function _ZN15Fl_XmlTokenizer9read_nextEv, 
which has no line number information.

    
Program received signal SIGINT, Interrupt.
0x0feff060 in Fl_XmlTokenizer::is_literal ()
   from /usr/local/lib/libefltk_xml.so.2.0
(gdb) 

It seems to be looping the same functions forever I guess.  This is what strace prints when it is locked up:
mremap(0x3004a000, 13393920, 13398016, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13398016, 13402112, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13402112, 13406208, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13406208, 13410304, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13410304, 13414400, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13414400, 13418496, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13418496, 13422592, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13422592, 13426688, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13426688, 13430784, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13430784, 13434880, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13434880, 13438976, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13438976, 13443072, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13443072, 13447168, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13447168, 13451264, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13451264, 13455360, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13455360, 13459456, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13459456, 13463552, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13463552, 13467648, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13467648, 13471744, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13471744, 13475840, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13475840, 13479936, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13479936, 13484032, MREMAP_MAYMOVE) = 0x3004a000
mremap(0x3004a000, 13484032, 13488128, MREMAP_MAYMOVE) = 0x3004a000

[karijes]

Logged In: YES 
user_id=832040

Sorry for latter response.

>I don't think efltk or ede was compiled with -g but I
don't know how to take advantage of that if it were.

If you run ./configure --enable-debug for efltk and ede you
already have it. After you run it in gdb and crash occured,
just run 'backtrace' in gdb too. This should provide enough
informations.

Anyway, already posted data is very usefull, and big thanks
for that! If you find some time, just pass it througt 
backtrace (first use --enable-debug in configure) and
repost it here.

Thanks again.
Sanel 

[nobody]

Logged In: NO 

I have the same problem with ede compiled for the zaurus
(arm toolchain).

I observed that the compiler warns in XmlTokenizer that -1
is illegal for char.

That seems to result in the effect described below.

When doing a quick hack (setting it to 255 instead) the menu
works now.

[aholzer]

Logged In: YES 
user_id=632342

Oncemore with login ...

That's the code making problems ...

putback_char = -1;

[vljubovic]

Logged In: YES 
user_id=110776

Thanks for your post. Obviously this assignment gives 
unexpected result on big-endian platform. I will patch 
this but don't close this bug until others confirm that 
this solution works. 

[vljubovic]

Logged In: YES 
user_id=110776

civilian-rus confirmed that everything is fine now on his 
Zaurus. konsolefreak, please test the latest SVN. 

[konsolefreak]

Logged In: YES 
user_id=1502924

I got the latest SVN (not CVS) and applied that efltk gcc4 patch(some parts were already applied) and it cempiled with gcc-4.1.1! The menu works now too!