unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Roland Orre <roland.orre@neurologic.se>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guile-user@gnu.org
Subject: Re: Debugging hints wanted
Date: Tue, 01 Jul 2008 16:24:49 +0200	[thread overview]
Message-ID: <1214922290.6032.160.camel@localhost.localdomain> (raw)
In-Reply-To: <877ic5okm2.fsf@gnu.org>

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

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






  reply	other threads:[~2008-07-01 14:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-04 19:19 guile-pg - debian David Pirotte
2008-02-04 21:40 ` Eric Cooper
2008-06-30 16:56   ` Debugging hints wanted Roland Orre
2008-06-30 19:42     ` Ludovic Courtès
2008-07-01 10:14       ` Roland Orre
2008-07-01 12:27         ` Ludovic Courtès
2008-07-01 14:24           ` Roland Orre [this message]
2008-07-01 15:00             ` Ludovic Courtès
2008-02-05 14:26 ` guile-pg - debian Greg Troxel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1214922290.6032.160.camel@localhost.localdomain \
    --to=roland.orre@neurologic.se \
    --cc=guile-user@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).