From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Roland Orre Newsgroups: gmane.lisp.guile.user Subject: Re: Debugging hints wanted Date: Tue, 01 Jul 2008 16:24:49 +0200 Message-ID: <1214922290.6032.160.camel@localhost.localdomain> References: <20080204171945.4175db40@altosw.be> <20080204214003.GB2646@stratocaster.home> <1214844983.6032.96.camel@localhost.localdomain> <87zlp2g15m.fsf@gnu.org> <1214907252.6032.130.camel@localhost.localdomain> <877ic5okm2.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1214922315 14463 80.91.229.12 (1 Jul 2008 14:25:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Jul 2008 14:25:15 +0000 (UTC) Cc: guile-user@gnu.org To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Jul 01 16:26:01 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KDgns-00014G-Ic for guile-user@m.gmane.org; Tue, 01 Jul 2008 16:25:56 +0200 Original-Received: from localhost ([127.0.0.1]:49443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDgn1-0006of-Or for guile-user@m.gmane.org; Tue, 01 Jul 2008 10:25:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KDgmx-0006oT-Gm for guile-user@gnu.org; Tue, 01 Jul 2008 10:24:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KDgmv-0006o3-UF for guile-user@gnu.org; Tue, 01 Jul 2008 10:24:59 -0400 Original-Received: from [199.232.76.173] (port=33935 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDgmv-0006o0-OL for guile-user@gnu.org; Tue, 01 Jul 2008 10:24:57 -0400 Original-Received: from csmtp1.one.com ([195.47.247.21]:47447 helo=csmtp1.b-one.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KDgmq-0003kx-Q8; Tue, 01 Jul 2008 10:24:53 -0400 Original-Received: from dyna224-183.nada.kth.se (dyna224-183.nada.kth.se [130.237.224.183]) by csmtp1.b-one.net (Postfix) with ESMTP id 569599883277; Tue, 1 Jul 2008 16:24:51 +0200 (CEST) In-Reply-To: <877ic5okm2.fsf@gnu.org> X-Mailer: Evolution 2.6.1 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6620 Archived-At: Hi again, and thanks for the hints. On Tue, 2008-07-01 at 14:27 +0200, Ludovic Court=E8s wrote: > Roland Orre 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 rewor= k, > > possibly causing other issues as the old array API is used in=20 > > hundreds of places in my code, and there may be other API changes > > as well. >=20 > 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. >=20 > 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.=20 > 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