Red Hat Bugzilla – Bug 437133
ddd fails to start (segmentation fault)
Last modified: 2009-07-25 05:34:04 EDT
Description of problem: Trying to run ddd, fails to start. Brief flash of a window appears then prints out "Internal error (Aborted)". Version-Release number of selected component (if applicable): ddd-3.3.11-18.fc9.x86_64 How reproducible: Everytime Steps to Reproduce: 1. Run ddd Actual results: Prints out a message with "Oops! You've found a bug in DDD" Expected results: ddd starts up Additional info:
Created attachment 297791 [details] ~/.ddd/log DDD log file
Created attachment 297792 [details] Backtrace Backtrace from GDB
I can't reproduce this failure on my rawhide x86_64 system, with all updates applied. Are you fully updated?
It is fully updated. The machine I have is recently upgraded to rawhide from F8.
Well, this is going to be difficult to debug if I can't reproduce it. Your GDB backtrace doesn't really say much... can you try: mv ~/.ddd ~/.ddd-old yum remove ddd yum install ddd.x86_64 After that, see if it still segfaults. Is anything else abnormal (or are any other failures occurring)? What hardware is it?
Still the same. The HW is a Dell Precision 390. I also get the same problem on my home x86_64 machine (various assembled bits and bobs). This has also followed a similar upgrade path, i.e. F8->Rawhide (with a few bits not upgraded - kernel and X server). I've started playing around because I inadvertently discovered that running as root works. Further playing (not as root) shows that ddd aborts if MALLOC_CHECK_ is set to 2 (which seems to be my default) and prints out the following with MALLOC_CHECK_ set to 1: *** glibc detected *** ddd: free(): invalid pointer: 0x00002aaaaf530010 *** *** glibc detected *** ddd: free(): invalid pointer: 0x0000000000a16f70 ***
I can reproduce it with MALLOC_CHECK_=2, which isn't the default on my end.
It looks like this is hitting lesstif, specifically: lib/Xm-2.1/XpmCrPFrDat.c if (pixmap_return && ximage) { xpmCreatePixmapFromImage(display, d, ximage, pixmap_return); XDestroyImage(ximage); } That XDestroyImage call is what is triggering the MALLOC_CHECK_ failure.
Do you have lesstif or lesstif,x86_64 installed? Just trying to eliminate things.
lesstif.x86_64 - the only thing on my system that requires it is ddd.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I just tested this in FC9 x86_64 live, and can't reproduce it at all. I ran: $ env MALLOC_CHECK=2 ddd and it ran perfectly. Am I attempting to reproduce this properly?
You're missing the trailing underscore on MALLOC_CHECK_
Just finished building 3.3.12-test-2 and testing locally, and got the same. I'l see if upstream has any thoughts.
Created attachment 309355 [details] Partial valgrind output showing buffer overflow I can reproduce this on Ubuntu 8.04, so it looks like an upstream bug. valgrind shows an invalid write (buffer overflow) near the crash. I don't know yet whether this is ddd or lesstif problem. I'm actually working on porting DDD to Gtk - I'm not too familiar with the Motif and Xlib stuff (well, I was... about 10 years ago... but this stuff has been consigned to the lumber room of my memory).
I think it's a lesstif bug. This is the function which does the damage (from Xpmcreate.c): #if !defined(WORD64) && !defined(LONG64) static int PutPixel32(ximage, x, y, pixel) register XImage *ximage; int x; int y; unsigned long pixel; { unsigned char *addr; if(x < 0 || y < 0) return 0; addr = &((unsigned char *)ximage->data) [ZINDEX32(x, y, ximage)]; *((unsigned long *)addr) = pixel; return 1; } #endif Note that unsigned long is 64, not 32, bits. So writing the last pixel will overflow the buffer. It looks to me as if some attempt has been made to cope with 64-bit systems (the #if defined... macro) but clearly this has not been successful.
lesstif-0.95.0-25, which fixes this is on its way to rawhide, F-9 updates and F-8 updates.
lesstif-0.95.0-25.fc9 has been submitted as an update for Fedora 9
lesstif-0.95.0-25.fc8 has been submitted as an update for Fedora 8
lesstif-0.95.0-25.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
lesstif-0.95.0-25.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #16) > It looks to me as if some attempt has been made to cope with 64-bit systems (the > #if defined... macro) but clearly this has not been successful. The reason why this part of the code gets called is because LONG64 has not been defined properly in include/Motif-2.1/XmI/XpmI.h In the debian package we solve this problem by including the definition of LONG64 from the X11 headers (/usr/include/X11/Xtos.h) I will also do this for lesstif upstream shortly. See also the debian bugtracker at http://bugs.debian.org/503361