On Fri, Nov 14, 2003 at 06:30:07AM -0800, J Robinson wrote:

> 
> I have been able to reproduce the segfault from the
> command line using my SWISH::API client. Examining the
> resulting core dump file always leads to a call to
> 'chunk_free()' -- here's a typical stack trace:

That's ugly.  

So you cannot make it happen with the swish-e binary, right?  There's
not a huge difference in the way the binary and the C API work.  And
there's not a lot of work going on in the API.xs code.  Did you try with
a different version of Perl?

> The five stack traces I examined were all different,
> but all went through 'Perl_runops_standard ()' and
> ended with chunk_free().

I don't know about Perl_runopts_standard(), but I might expect to see 
things show up during memory management.

Too bad there's not more detail with the following output.  It would be 
a lot more helpful if our debugging have hints about where in the 
source this was happening.

Might be helpful to have MEM_ERROR() throw a segfault on purpose to get 
a back trace.  These are just reporting the problem in a function that's 
used by a lot of code.

> ..(searching) ...
> Memory free error! At mem.c line 653
> Already free: 08A9B8A8
> 
> Memory free error! At mem.c line 653
> Head Guard 1 overwritten: 08A9B898
> 
> Memory free error! At mem.c line 653
> Head Guard 2 overwritten: 08A9B8A4
> 
> Memory free error! At mem.c line 653
> Tail Guard overwritten: 08A9B8A7
> 

And this last one is a bit odd.  Red herring or true memory corruption?

> Memory free error! At metanames.c line 403
> Address FFFFFFFF not longword aligned

That's:

     efree( meta->metaName );

and there are not that meta structures many so might be able to catch
that with gdb and a watch statement.

Yep, ugly.  I would try different version of Perl.  Since you suspect 
large properties, maybe build --without-zlib and reindex and try again.  
It would be really great if you could get the segfault outside of Perl.


-- 
Bill Moseley
moseley@hank.org