[lammps-users] XMovie Problem-->Bug ID 5675757: Segmentation Fault using X11

Okay… the very nice people at Apple found the cause of the bug in the Xmovie code. A block of memory is freed and then referenced. See below. I took a stab at fixing the problem, but just don’t know enough about this code. I have also included at the bottom a list of the “warnings” that I get when I make xmovie. They may mean nothing, or they may be part of the problem on this platform since they are all references to pointers.

-Carolyn

From: devbugs@…646…
Date: January 15, 2008 6:45:55 PM GMT-05:00
To: phillicl@…398…
Subject: Bug ID 5675757: Segmentation Fault using X11

Hi Carolyn,

This is a follow-up to Bug ID# 5675757.

Engineering has provided the following feedback regarding this issue:

This is a bug in the code of the program.

If you add some debug statements to the beginning of NewData in read.c:

if (Common.ndata >= Common.maxdata) { /* need to realloc */
Common.maxdata += 256;
Common.dataptr = (DATA *) XtRealloc((char *) Common.dataptr,
Common.maxdata * sizeof(DATA));
printf(“Realloced; maxdata=%d (%d), dataptr=%p, buf end = %p\n”,
Common.maxdata, Common.maxdata * sizeof(DATA),
Common.dataptr, Common.dataptr + Common.maxdata);
}
printf(“Common.dataptr = %p, Common.ndata = %d\n”, Common.dataptr, Common.ndata);
current_data = Common.dataptr + Common.ndata;
Common.ndata++;

You’ll see the following output under gdb:
Common.dataptr = 0x2ca000, Common.ndata = 250
Common.dataptr = 0x2ca000, Common.ndata = 251
Common.dataptr = 0x2ca000, Common.ndata = 252
Common.dataptr = 0x2ca000, Common.ndata = 253
Common.dataptr = 0x2ca000, Common.ndata = 254
Common.dataptr = 0x2ca000, Common.ndata = 255
Realloced; maxdata=512 (30720), dataptr=0x2e7000, buf end = 0x2ee800
Common.dataptr = 0x2e7000, Common.ndata = 256

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x002cdbc4
0x0000777b in NewData () at read.c:735
735 current_data->time = last_data->time;
(gdb) print last_data
$1 = (DATA *) 0x2cdbc4

The problem here is that the code calls XtRealloc, which (sometimes) returns a new pointer to a new block of memory (0x2e7000). It then tries to access the old memory (0x2ca000 + 15300), which was freed by XtRealloc when it allocated the new, larger buffer.

We consider this issue closed. Thank you for taking the time to notify us of this issue.

Best Regards,

Allison Vanderby
Apple Developer Connection
Worldwide Developer Relations


THE INFORMATION CONTAINED IN THIS MESSAGE IS UNDER NON-DISCLOSURE



Bug ID #: 5675757
Bug Title: Segmentation Fault using X11

<GMT08-Jan-2008 19:07:07GMT> Carolyn Phillips:
I am using a piece of software called xmovie that is packaged with LAMMPS (produced by Sandia National Labs, see http://lammps.sandia.gov/doc/Section_tools.html#xmovie))
Xmovie is a X-based visualization package. I discovered that when I sent more than precisely 256 timeframes of data to xmovie, the application crashed due to a segmentation fault, at the code line XtAppMainLoop(AppContext);

No other user on any other platform (and there are plenty!) using xmovie has reported having this problem, and I have reproduced this problem on two separate identically configured mac osx systems, so I suspect it has something to do with the X11 application on Mac OS X 10.4. I have the standard x window system that the mac came installed with X11 1.1.3 - XFree86 4.4.0. (I say again, I do not believe this is an issue with xmovie itself, which is why I bring this to your attention)

I have included a zipped xmovie folder, which I got by downloading the most recent (October 07) version of LAMMPS from http://lammps.sandia.gov/download.html
It is only necessary to build xmovie to reproduce this problem, which is in the file /lammps-“date”/tools/xmovie and requires only that one line in the makefile be uncommented and one be commented.

If you then run ./xmovie dummy.dat you will get the segmentation fault
if you
head -n 1028 dummy.dat > temp
(which is equivalent to 256 time frames) and then
./xmovie temp
the application will run fine. (and yes… I have verified that it doesn’t matter which 256 time frames are used!)
head -n 1032 dummy.dat > temp
(257 timeframes) will produce a segementation fault.

Thanks!

‘xmovie.zip’ was successfully uploaded

udhcp-macvpn-832:xmovie-> make
gcc -c -O2 -finline-functions -g -DMISSINGDEFS -D_POSIX_SOURCE -DUSEPRIVATE -DINCL_FLOAT -Wimplicit -Wunused -Wmissing-prototypes xmovie.c
gcc -c -O2 -finline-functions -g -DMISSINGDEFS -D_POSIX_SOURCE -DUSEPRIVATE -DINCL_FLOAT -Wimplicit -Wunused -Wmissing-prototypes control.c
gcc -c -O2 -finline-functions -g -DMISSINGDEFS -D_POSIX_SOURCE -DUSEPRIVATE -DINCL_FLOAT -Wimplicit -Wunused -Wmissing-prototypes scene.c
scene.c: In function ‘MotionUpdate’:
scene.c:155: warning: passing argument 4 of ‘XpmWriteFileFromPixmap’ makes integer from pointer without a cast
scene.c: In function ‘SceneSave’:
scene.c:188: warning: passing argument 4 of ‘XpmWriteFileFromPixmap’ makes integer from pointer without a cast
gcc -c -O2 -finline-functions -g -DMISSINGDEFS -D_POSIX_SOURCE -DUSEPRIVATE -DINCL_FLOAT -Wimplicit -Wunused -Wmissing-prototypes read.c
read.c: In function ‘SortData’:
read.c:980: warning: passing argument 1 of ‘hpsort’ from incompatible pointer type
read.c:980: warning: passing argument 4 of ‘hpsort’ from incompatible pointer type
gcc -c -O2 -finline-functions -g -DMISSINGDEFS -D_POSIX_SOURCE -DUSEPRIVATE -DINCL_FLOAT -Wimplicit -Wunused -Wmissing-prototypes hpsort.c
hpsort.c:11: warning: no previous prototype for ‘hpsort’
hpsort.c: In function ‘hpsort’:
hpsort.c:18: warning: implicit declaration of function ‘malloc’
hpsort.c:18: warning: incompatible implicit declaration of built-in function ‘malloc’
hpsort.c:21: warning: implicit declaration of function ‘memcpy’
hpsort.c:21: warning: incompatible implicit declaration of built-in function ‘memcpy’
hpsort.c:23: warning: incompatible implicit declaration of built-in function ‘memcpy’
hpsort.c:35: warning: incompatible implicit declaration of built-in function ‘memcpy’
hpsort.c:40: warning: incompatible implicit declaration of built-in function ‘memcpy’
hpsort.c:42: warning: implicit declaration of function ‘free’
gcc -c -O2 -finline-functions -g -DMISSINGDEFS -D_POSIX_SOURCE -DUSEPRIVATE -DINCL_FLOAT -Wimplicit -Wunused -Wmissing-prototypes version.c
gcc -o xmovie -O2 -finline-functions -g version.o xmovie.o control.o scene.o read.o hpsort.o -L/usr/X11R6/lib -lX11 -lXaw -lXt -lXext -lXmu -lXpm

Xmovie isn't my code either, so I'll take a quick look,
but may not be able to fix it easily.

Steve

Thanks the gdb output was useful. I fixed the bug and posted
a patch. If you can now run xmovie on a Mac, please send
me the Makefile. I don't think I've run it before on my Mac.

Steve