Re: Debugging hints wanted

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Roland Orre <roland.orre@neurologic.se> writes:

> That's a good hint. I'll check out the code and see if I can locate
> the changes. Problem is that I've considered switching a few years,
> but since the array API changed from 1.8 it would imply a major rework,
> possibly causing other issues as the old array API is used in 
> hundreds of places in my code, and there may be other API changes
> as well.

The array API has been the same in all releases of the 1.8.x series.

>> > My bigger problem though is frequently occurring 
>> > segmentation faults or otherwise corrupt pointers.
>> >
>> >  If I then run the code in gdb I can get
>> > Program received signal SIGSEGV, Segmentation fault.
>> > [Switching to Thread 0x2ae316e4f070 (LWP 6699)]
>> > 0x00002ae314b9d091 in scm_gc_mark_dependencies (p=0x97c) at
>> > gc-mark.c:441
>> > 441      if (SCM_GC_MARK_P (ptr))
>> > Current language:  auto; currently c
>> 
>> Likewise, is it reproducible?  Can you show the full backtrace (it
>> should show where 0x97c comes from)?
>
> This is fully reproducible when it happens as shown. Most often
> I get a segmentation fault like this. I have attached a full
> gdb backtrace from this. This can be produced over and over
> with only base address differences.

The backtrace shows this is called from `scm_mark_locations ()', which
would indicate the stack contains the offending bogus pointer, which is
bad.

Can you please try that out with 1.8.5?

Thanks,
Ludovic.