mapserver receives SIGABRT from glibc

[dirk@…]

I am using mapserver rel_4_6_0 from CVS on Gentoo development branch. After a
system (incl. glibc) upgrade mapserver did not work anymore. I waited a few more
glibc upgrades without change. I'm getting the following message (maptest is a
simple C program that opens the map and requests drawing):
dirk@junge ~/src/mapserver $ ./maptest 
*** glibc detected *** double free or corruption (!prev): 0x082ade00 ***
Aborted

(gdb) r
Starting program: /home/dirk/src/mapserver/maptest 
*** glibc detected *** double free or corruption (!prev): 0x08348e00 ***

Program received signal SIGABRT, Aborted.
0xb77b19b1 in kill () from /lib/libc.so.6
(gdb) bt
#0  0xb77b19b1 in kill () from /lib/libc.so.6
#1  0xb77b1635 in raise () from /lib/libc.so.6
#2  0xb77b2d4d in abort () from /lib/libc.so.6
#3  0xb77e48cc in __fsetlocking () from /lib/libc.so.6
#4  0xb77edc77 in mallopt () from /lib/libc.so.6
#5  0xb77ec7cf in mallopt () from /lib/libc.so.6
#6  0xb77edd8f in free () from /lib/libc.so.6
#7  0xb77dbd8a in fclose () from /lib/libc.so.6
#8  0x080932b3 in loadSymbolSet (symbolset=0x80e5204, map=0x6) at mapsymbol.c:643
#9  0x080581cf in loadMapInternal (filename=0x80c7840
"/usr/local/stc-lbs/maps.001/orient.map", 
    new_mappath=0x0) at mapfile.c:4340
#10 0x0804cc9b in main (argc=1, argv=0xbface8a4) at maptest.c:22

Setting a awatch point on msyyin, which is fclosed in mapsymbol.c:643 shows that
the file is closed in mapsymbol.c:389 before. The reason for that is a bug in my
symbol file. A patch will be attached that solved the problem for me.

I believe that it is the responsibility of glibc to check for validity of file
descriptors. However, when mapserver can be more clean ... why not.

[dirk@…]

One solution to avoid fclosing files twice

[sdlime]

Dirk: Is "fileno" available everywhere? I've not used it before and want to 
make sure we don't run into issues where it's not available on Windows for some 
reason.

Steve

[dirk@…]

Hi Steve,

thank you for your reply. My manual page does not explicitely mention fileno as
conforming to any standard, but since there are other functions on the same
man-page that do conform, I guess fileno might not even be able on other UNIX
systems (double checked with IRIX and they have it).

However, the attached patch was intended to prove that 'free' is the reason for
the abort signals and I'm using fileno only to test if a file is a valid one. In
my eyes the right patch would be to get rid of the fclose calls for the error
cases where the execution continues til the end of the function.

msdn.microsoft.com indicates that fileno has been at least available on Windows:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarw98bk/html/fileoperations.asp

Dirk.

[dmorissette]

I got the same error while testing a mapfile with a symbolset larger than MS_MAXSYMBOLS in MapServer 4.99 (5.0 dev).

Simply setting msyyin = NULL after closing it and checking whether it is NULL before calling fclose() should solve the current issue, right? At least that works for me.

Fixed in SVN r6326

[dmorissette]

Note that I was unable to reproduce the error with MapServer 4.10, so it seems that the case that I ran into was specific to the codepath of v4.99-dev