[Xastir-dev] Raw Tiger code, --with-libgc = segfault

Curt, WE7U archer at eskimo.com
Tue Nov 2 11:07:05 EST 2004


I get a segfault if I run with libgc enabled (that's our memory leak
detector), with raw tiger maps and "Filled" checked in the Map
Chooser->Properties dialog for those maps.

That "Filled" option triggers the polygon new reassembly code.  I
believe I've tracked it down to libgc deallocating some memory
before we're done with it.  A quick check of the README.QUICK from
the libgc distribution yielded this:


  "Do not store the only pointer to an object in memory allocated
  with system malloc, since the collector usually does not scan
  memory allocated in this way."


All I can say is, that sucks.  In this case I'm malloc'ing memory,
storing it in three hashes, then later coming along and combining
those hashes, malloc'ing more memory that gets attached in the form
of a linked list to the end of structs in the first hash.  I'm
definitely violating the paragraph above, but changing the entire
structure of the code just to satisfy that paragraph is kind of
ridiculous.

Any of you software types have a quick/easy way around this other
than keeping a separate list of pointers?  Since I don't know
beforehand how many I'm going to have, I could allocate one pointer
variable and just create a linked list of these other structs, but
that would probably stop the memory-leak detection for these structs
from working.  Not what I had in mind.

I'll look at the libgc docs some more to see if it can be made to
scan malloc'ed memory in all cases.  Perhaps I'm using the wrong
libgc function to allocate the memory and causing it to skip looking
for pointers there, or the garbage collector can be put into a
smarter or at least more thorough mode for that memory.

--
Curt, WE7U			         http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"



More information about the Xastir-dev mailing list