Hi, Roland Orre <[EMAIL PROTECTED]> 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.
