[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging hints wanted

From: Ludovic Courtès
Subject: Re: Debugging hints wanted
Date: Tue, 01 Jul 2008 14:27:17 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)


Roland Orre <address@hidden> 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

Can you please try that out with 1.8.5?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]