Ticket #603 (closed defect: fixed)

Opened 9 years ago

Last modified 7 years ago

segfault with shp2img, valgrind output included

Reported by: slaven@… Owned by: sdlime
Priority: low Milestone: 4.6 release
Component: Command Line Utilties Version: unspecified
Severity: critical Keywords:
Cc:

Description

The summary says it all. Please tell so, if you need the source map and shp
files.

Regards,
    Slaven

==9646== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==9646== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==9646== Using valgrind-2.0.0, a program supervision framework for x86-linux.
==9646== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==9646== Estimated CPU clock rate is 2403 MHz
==9646== For more details, rerun with: -v
==9646== 
==9646== Conditional jump or move depends on uninitialised value(s)
==9646==    at 0x420BD30B: re_search_internal (in /lib/i686/libc-2.2.93.so)
==9646==    by 0x420C2DF4: __regexec (in /lib/i686/libc-2.2.93.so)
==9646==    by 0x804BBF7: msEvalRegex (mapfile.c:53)
==9646==    by 0x8053D97: loadMapInternal (mapfile.c:4031)
==9646== 
==9646== Conditional jump or move depends on uninitialised value(s)
==9646==    at 0x420BD30B: re_search_internal (in /lib/i686/libc-2.2.93.so)
==9646==    by 0x420C2DF4: __regexec (in /lib/i686/libc-2.2.93.so)
==9646==    by 0x8055383: msEvalExpression (maputil.c:134)
==9646==    by 0x8055463: msShapeGetClass (maputil.c:168)
==9646== 
==9646== Invalid read of size 1
==9646==    at 0x80733AC: msGetBit (mapbits.c:23)
==9646==    by 0x807B77B: msFilterTreeSearch (maptree.c:745)
==9646==    by 0x80763FB: msSHPWhichShapes (mapshape.c:1319)
==9646==    by 0x805BFF1: msLayerWhichShapes (maplayer.c:193)
==9646==    Address 0x42E9BF4B is 0 bytes after a block of size 727 alloc'd
==9646==    at 0x40025B89: calloc (vg_replace_malloc.c:284)
==9646==    by 0x807338A: msAllocBitArray (mapbits.c:15)
==9646==    by 0x807B069: msSearchDiskTree (maptree.c:497)
==9646==    by 0x80763C6: msSHPWhichShapes (mapshape.c:1315)
==9646== 
==9646== Invalid read of size 1
==9646==    at 0x80733AC: msGetBit (mapbits.c:23)
==9646==    by 0x805C1FD: msLayerNextShape (maplayer.c:270)
==9646==    by 0x805E56B: msDrawVectorLayer (mapdraw.c:690)
==9646==    by 0x805E28C: msDrawLayer (mapdraw.c:573)
==9646==    Address 0x42E9BF4B is 0 bytes after a block of size 727 alloc'd
==9646==    at 0x40025B89: calloc (vg_replace_malloc.c:284)
==9646==    by 0x807338A: msAllocBitArray (mapbits.c:15)
==9646==    by 0x807B069: msSearchDiskTree (maptree.c:497)
==9646==    by 0x80763C6: msSHPWhichShapes (mapshape.c:1315)
==9646== 
==9646== Conditional jump or move depends on uninitialised value(s)
==9646==    at 0x808DA92: tweenColorTest (gdft.c:516)
==9646==    by 0x809012A: gdCacheGet (gdcache.c:108)
==9646==    by 0x808DE9D: gdft_draw_bitmap (gdft.c:743)
==9646==    by 0x808E47E: gdImageStringFTEx (gdft.c:1109)
==9646== 
==9646== More than 30000 total errors detected.  I'm not reporting any more.
==9646== Final error counts will be inaccurate.  Go fix your program!
==9646== Rerun with --error-limit=no to disable this cutoff.  Note
==9646== that errors may occur in your program without prior warning from
==9646== Valgrind, because errors are no longer being displayed.
==9646== 
==9646== 
==9646== ERROR SUMMARY: 30000 errors from 5 contexts (suppressed: 248 from 2)
==9646== malloc/free: in use at exit: 70795 bytes in 129 blocks.
==9646== malloc/free: 73861 allocs, 73732 frees, 7394807 bytes allocated.
==9646== For a detailed leak analysis,  rerun with: --leak-check=yes
==9646== For counts of detected errors, rerun with: -v

Change History

Changed 9 years ago by sdlime

Sample shapefiles and mapfiles are always helpful, please attach if you can. 
Otherwise I have no way to recreate the problem.

Also, what version are we talking about? We won't fix anything but the dev 
version, but will want to verify that the issue exists there too...

Steve

Changed 9 years ago by slaven@…

> Sample shapefiles and mapfiles are always helpful, please attach if you can. 
> Otherwise I have no way to recreate the problem.

I made tarballs and put them on http://bbbike.sourceforge.net/tmp/
You need both .tar.gz, one holds the map and shp files, the other
has additional images.

> Also, what version are we talking about? We won't fix anything but the dev 
> version, but will want to verify that the issue exists there too...
> 

It's a fresh CVS checkout.


[BTW, the mail address <bugzilla-daemon@lists.gis.umn.edu> seems to be invalid]

Changed 9 years ago by slaven@…

... plus you need a.map from the mentioned URL. The command line which
causes the segfault is:

   shp2img -m a.map -e 8000 8000 9000 9000 

Changed 8 years ago by bill@…

Steve, this might be fixed with the recent regex fixes: perhaps you or Slaven
could retest with 4.6b2?

Changed 8 years ago by slaven@…

It seems that the segfault is not fixed with the latest CVS version.

It seems that the instructions how to reproduce the bug were somewhat sparse,
so here is a step-to-step description:

* Download http://bbbike.sourceforge.net/tmp/bbbike-images.tar.gz

* Download http://bbbike.sourceforge.net/tmp/mapserver-brb.tar.gz

* Create a directory /tmp/mstest

* Create a directory /tmp/mstest/bbbike

* cd to /tmp/mstest and extract mapserver-brb.tar.gz

* cd to /tmp/mstest/bbbike and extract bbbike-images.tar.gz

* cd to /tmp/mstest/mapserver/brb and fix the paths:

   perl -pi.bak -e 's{/home/slavenr/work2/}{/tmp/mstest/}g' *

  Ignore the errors about unregular files.

* Try to create an image:

  shp2img -m brb.map -e 8000 8000 9000 9000

This creates a core dump on my machine:

  zsh: 24265 segmentation fault (core dumped)  ~/work2/mapserver/shp2img -m
brb.map -e 8000 8000 9000 9000

The gdb backtrace:

(gdb) bt
#0  msFirstKeyFromHashTable (table=0x8126978) at maphash.c:235
#1  0x08079de6 in msApplyMapConfigOptions (map=0x80f0e20) at mapobject.c:249
#2  0x080576fd in loadMapInternal (filename=0x80f0e20 "&#65533;\005\017\b\001", 
    new_mappath=0x0) at mapfile.c:4328
#3  0x0804c868 in main (argc=8, argv=0xbfffe834) at shp2img.c:92
#4  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

HTH
    Slaven

Changed 8 years ago by sdlime

  • status changed from new to assigned
  • milestone set to 4.6 release
Will get this fixed in 4.6.1...

Steve

Changed 7 years ago by slaven@…

  • status changed from assigned to closed
  • resolution set to fixed
I am happy to say that I cannot reproduce the error anymore with a current CVS
build.

The output of shp2img -v is:
MapServer version 4.10.0-beta3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP
OUTPUT=SVG SUPPORTS=FREETYPE INPUT=EPPL7 INPUT=SHAPEFILE

Thanks,
    Slaven

Note: See TracTickets for help on using tickets.