Re: Debugging hints wanted

[Roland Orre]

Hi again, and thanks for the hints.
On Tue, 2008-07-01 at 14:27 +0200, Ludovic Courtès wrote:
> 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.

Yes, but I'm still using 1.7 because of the changes in API from
1.7 to 1.8. I haven't investigated this deeply though, hopefully
easy to make some compatibility macros. In most modules I use
SCM_VELTS, SCM_UVECTOR_LENGTH, SCM_VECTOR_LENGTH, scm_make_vector,
scm_make_uvector,SCM_UVECTOR_BASE,SCM_BITVECTOR_LENGTH,
SCM_BITVECTOR_BASE, SCM_VALIDATE_VECTOR,SCM_WRITABLE_VELTS,
scm_array_set_x, scm_array_fill_x,scm_c_make_vector,
scm_c_make_uvector
(quick grep through the code)

I just counted the occurances of these above in the modules I use
daily and got 565. OK, if the macros can just be replaced, then
it would just be a few defines, but as I've understood they are
quite incompatible. This is a tedious work which would take me
a few weeks to certify that all changes are correct.

> > 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.
OK, that is a good hint. The most likely explanation for this then I
guess could be a discrepancy in some parameter somewhere, making the
stack off phase like int in one place and long which would be the
same on 32 bit. I'll check that all APIs are defined through
common includes. 

> Can you please try that out with 1.8.5?
Yes, I wish that would be easy... but I anticipate a lot of work
for that. Work with an uncertain outcome and very long pay off.

        Best regards
        Roland