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 12:14:11 +0200	[thread overview]
Message-ID: <1214907252.6032.130.camel@localhost.localdomain> (raw)
In-Reply-To: <87zlp2g15m.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3007 bytes --]

Hi Ludovic, thanks for your reply
On Mon, 2008-06-30 at 21:42 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Roland Orre <roland.orre@neurologic.se> writes:
> 
> > I need hints on how to find occasional segmentation faults
> > and missed GC references. This relates to 64 bit machines.
> 
> Is it x86-64, IA64, or something else?
What I'm trying to get working now is on x86-64 (Opteron) to be
able to run it on a big large memory computer IA64 (Itanium2).

> The Git repository (the future 1.8.6) contains an important bug fix for
> IA64.  I think there were x86-64-related during the 1.8.x series, too.
> Thus, I'd suggest using the latest Guile on these platforms.

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.

> > My modules have worked perfectly fine on 32 bit machines but
> > on 64 bits I occasionally get something like
> > #<freed cell 0x2...; GC missed a reference> if I run that
> > code fast, which indicates a threading problem (I do not use
> > threads in this case, but seems like guile does). This does
> > not occur if I run guile through gdb. This happens not too often
> > but it seems to be related to string->symbol symbol->string.
> 
> Is it reproducible?

This is not really reproducable. If I execute the lines quick by
loading it as a file then it occurs with about 60 % probability.
If I execute  the lines in that file, line by one, it does not
occur. To come around that I can see that it may be complaining
at e.g. a string->symbol conversion. If I then simply replace
that with the id  i.e. (lambda(x) x) then it doesn't happen
but probably this relates to the big issue below.

> > 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.

Sometimes I've got a pointer to some internal structure like
pointing to the procedure of a loop in the middle of a list of
numbers for instance, which is kind illogical as that internal
structure should not be freed. 

> Hope this helps,
> Ludovic.
Best regards
Roland

[-- Attachment #2: backtrace-full.txt --]
[-- Type: text/plain, Size: 10800 bytes --]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b966026a070 (LWP 25032)]
0x00002b965dfb8080 in scm_gc_mark_dependencies (p=0x97c) at gc-mark.c:441
441      if (SCM_GC_MARK_P (ptr))
(gdb) bt 30
#0  0x00002b965dfb8080 in scm_gc_mark_dependencies (p=0x97c) at gc-mark.c:441
#1  0x00002b965dfb800f in scm_gc_mark (ptr=0x97c) at gc-mark.c:137
#2  0x00002b965dfb844c in scm_mark_locations (x=0x7fff4d05ef68, n=1690)
    at gc-mark.c:467
#3  0x00002b965dfeaf1b in scm_threads_mark_stacks () at threads.c:996
#4  0x00002b965dfb7f15 in scm_mark_all () at gc-mark.c:94
#5  0x00002b965dfb75dc in scm_igc (what=0x2b965e129a00 "\001") at gc.c:571
#6  0x00002b965dfb749a in scm_gc_for_newcell (freelist=0x2b965e12cc80, 
    free_cells=0x562250) at gc.c:480
#7  0x00002b965df9d6f2 in scm_acons (key=0x2b965daccf10, value=0x2b9660cc9030, 
    alist=0x2b965dc2fee0) at ../libguile/inline.h:79
#8  0x00002b965dfb3afb in scm_dapply (proc=0x2b965dc2fec0, arg1=0x97c, 
    args=0x2b9660cc9030) at eval.c:4592
#9  0x00002b965dfaf32d in scm_apply (proc=0x2b965dc2fec0, arg1=0x2b965db1b9c0, 
    args=0x2b9660cc9050) at eval.c:4407
#10 0x00002b965dfaeab8 in scm_call_3 (proc=0x2b965dc2fec0, 
    arg1=0x2b965db1b9c0, arg2=0x97c, arg3=0x1) at eval.c:4280
#11 0x00002b965dfc9565 in module_variable (module=0x2b965db1b9c0, 
    sym=0x2b965db22060) at modules.c:291
#12 0x00002b965dfc95a2 in module_variable (module=0x2b965daff8e0, 
    sym=0x2b965db22060) at modules.c:301
#13 0x00002b965dfc9995 in scm_sym2var (sym=0x2b965db22060, proc=0x0, 
    definep=0x1) at modules.c:454
#14 0x00002b965dfb4792 in scm_defined_p (sym=0x2b965db22060, env=0x57c)
    at evalext.c:68
#15 0x00002b965dfb10a4 in scm_deval (x=0x97c, env=0x2b9660cc9900)
    at eval.c:3805
#16 0x00002b965dfb1ab0 in scm_deval (x=0x2b965dafb7d0, env=0x2b9660cc9900)
    at eval.c:3139
#17 0x00002b965dfb1b78 in scm_deval (x=0x2b9660aa2fb0, env=0x2b9660cc9900)
    at eval.c:3181
#18 0x00002b965dfb0e5f in scm_deval (x=0x2b965db75940, env=0x2b9660cc9bf0)
    at eval.c:2962
#19 0x00002b965dfb0e5f in scm_deval (x=0x2b965db752c0, env=0x2b9660cc9cc0)
    at eval.c:2962
#20 0x00002b965dfb1c0d in scm_deval (x=0x2b965dad3e50, env=0x2b9660cc6f50)
    at eval.c:3203
#21 0x00002b965dfb2c52 in scm_deval (x=0x2b965dae5970, env=0x2b9660cc7020)
    at eval.c:3799
#22 0x00002b965dfb0e5f in scm_deval (x=0x2b9660a9d970, env=0x2b9660bafa10)
    at eval.c:2962
#23 0x00002b965dfb0e5f in scm_deval (x=0x2b9660a7fce0, env=0x2b9660bafc70)
    at eval.c:2962
#24 0x00002b965dfb3ba2 in scm_dapply (proc=0x2b9660a88bc0, arg1=0x97c, 
    args=0x2b9660ba85f0) at eval.c:4619
#25 0x00002b965dfaf32d in scm_apply (proc=0x2b9660a88be0, arg1=0x2b965db24600, 
    args=0x2b965da82640) at eval.c:4407
#26 0x00002b965dfaea24 in scm_call_1 (proc=0x97c, arg1=0x1) at eval.c:4268
#27 0x00002b965dfafc1d in scm_map (proc=0x2b9660a88be0, arg1=0x2b965dbec760, 
    args=0x97c) at eval.c:5120
#28 0x00002b965dfb125f in scm_deval (x=0x97c, env=0x2b9660a96c80)
    at eval.c:3951
#29 0x00002b965dfb1e09 in scm_deval (x=0x2b9660a8e450, env=0x2b9660a96c80)
    at eval.c:3244
#30 0x00002b965dfb0e5f in scm_deval (x=0x2b9660a8e490, env=0x2b9660a96c80)
    at eval.c:2962
#31 0x00002b965dfb0db4 in scm_deval (x=0x2b9660a49c40, env=0x2b9660a4d790)
    at eval.c:2936
#32 0x00002b965dfb0db4 in scm_deval (x=0x2b9660a49df0, env=0x2b9660a4d790)
    at eval.c:2936
#33 0x00002b965dfb0454 in scm_i_eval_x (exp=0x97c, env=0x1) at eval.c:5398
#34 0x00002b965dfb04d5 in scm_primitive_eval_x (exp=0x2b9660a49670)
    at eval.c:5415
#35 0x00002b965dfc7d3c in load (data=0x97c) at load.c:78
#36 0x00002b965dfa540a in scm_internal_dynamic_wind (
    before=0x525218 <scm_i_root_state_key>, inner=0x2b965dfc7d20 <load>, 
    after=0x2b965dfc7cc0 <swap_port>, inner_data=0x2b96602775b0, 
    guard_data=0x7fff4d0605a0) at dynwind.c:144
#37 0x00002b965dfc7dfb in scm_primitive_load (filename=0x2b96602775b0)
    at load.c:107
#38 0x00002b965dfb1344 in scm_deval (x=0x97c, env=0x2b9660277520)
    at eval.c:4095
#39 0x00002b965dfb2c52 in scm_deval (x=0x2b965dbdcf20, env=0x2b9660277520)
    at eval.c:3799
#40 0x00002b965dfb0496 in scm_i_eval (exp=0x97c, env=0x2b9660277470)
    at eval.c:5405
#41 0x00002b965dfb0515 in scm_primitive_eval (exp=0x2b9660273710)
    at eval.c:5429
#42 0x00002b965dfb1344 in scm_deval (x=0x97c, env=0x2b9660272fd0)
    at eval.c:4095
#43 0x00002b965dfb0496 in scm_i_eval (exp=0x97c, env=0x2b9660272fd0)
    at eval.c:5405
#44 0x00002b965dfa31ab in scm_start_stack (id=0x5987a0, exp=0x2b965dac7190, 
    env=0x2b9660272fd0) at debug.c:455
#45 0x00002b965dfa323c in scm_m_start_stack (exp=0x2b965dac71a0, 
    env=0x2b9660272fd0) at debug.c:471
#46 0x00002b965dfb35f6 in scm_dapply (proc=0x2b965da865c0, 
    arg1=0x2b965dac71d0, args=0x2b9660272fd0) at eval.c:4480
#47 0x00002b965dfb318e in scm_deval (x=0x2b965dac71d0, env=0x2b9660272fd0)
    at eval.c:3645
#48 0x00002b965dfb1c0d in scm_deval (x=0x2b96602773e0, env=0x2b9660272fd0)
    at eval.c:3203
#49 0x00002b965dfb3ba2 in scm_dapply (proc=0x2b966026fc80, arg1=0x97c, 
    args=0x2b966026fd80) at eval.c:4619
#50 0x00002b965dfb2546 in scm_deval (x=0x2b965da88470, env=0x2b966026fd40)
    at eval.c:3558
#51 0x00002b965dfb2c52 in scm_deval (x=0x2b965daa4670, env=0x2b966026fa90)
    at eval.c:3799
#52 0x00002b965dfb3c08 in scm_dapply (proc=0x2b965daa2080, 
    arg1=0x2b965daa15b0, args=0x2b966026fa90) at eval.c:4615
#53 0x00002b965dfaf32d in scm_apply (proc=0x2b966026fa40, arg1=0x97c, 
    args=0x97c) at eval.c:4407
#54 0x00002b965dfaea03 in scm_call_0 (proc=0x97c) at eval.c:4262
#55 0x00002b965dfa2b59 in with_traps_inner (data=0x97c) at debug.c:91
#56 0x00002b965dfa540a in scm_internal_dynamic_wind (
    before=0x525218 <scm_i_root_state_key>, 
    inner=0x2b965dfa2b50 <with_traps_inner>, 
    after=0x2b965dfa2b40 <with_traps_after>, inner_data=0x2b966026fa40, 
    guard_data=0x7fff4d0611bc) at dynwind.c:144
#57 0x00002b965dfa2b9b in scm_with_traps (thunk=0x2b966026fa40) at debug.c:101
#58 0x00002b965dfb1344 in scm_deval (x=0x97c, env=0x2b966026f9f0)
    at eval.c:4095
#59 0x00002b965dfb3ba2 in scm_dapply (proc=0x2b966026f980, arg1=0x97c, 
    args=0x2b966026f9f0) at eval.c:4619
#60 0x00002b965dfaf32d in scm_apply (proc=0x2b966026f9a0, arg1=0x97c, 
    args=0x97c) at eval.c:4407
#61 0x00002b965dfaea03 in scm_call_0 (proc=0x97c) at eval.c:4262
#62 0x00002b965dfa540a in scm_internal_dynamic_wind (
    before=0x525218 <scm_i_root_state_key>, inner=0x2b965dfae9f0 <scm_call_0>, 
    after=0x2b965df9e510 <increase_block>, inner_data=0x2b966026f9a0, 
    guard_data=0x0) at dynwind.c:144
#63 0x00002b965df9e5fc in scm_call_with_unblocked_asyncs (proc=0x2b966026f9a0)
    at async.c:348
#64 0x00002b965dfb1344 in scm_deval (x=0x97c, env=0x2b966026f950)
    at eval.c:4095
#65 0x00002b965dfb3ba2 in scm_dapply (proc=0x2b966026f840, arg1=0x97c, 
    args=0x2b966026f950) at eval.c:4619
#66 0x00002b965dfaf32d in scm_apply (proc=0x2b966026f860, arg1=0x97c, 
    args=0x97c) at eval.c:4407
#67 0x00002b965dfaea03 in scm_call_0 (proc=0x97c) at eval.c:4262
#68 0x00002b965dfec27d in scm_body_thunk (body_data=0x97c) at throw.c:316
#69 0x00002b965dfec160 in scm_internal_lazy_catch (tag=0x37c, 
    body=0x2b965dfec270 <scm_body_thunk>, body_data=0x7fff4d0616b0, handler=0, 
    handler_data=0xa) at throw.c:248
#70 0x00002b965dfec5fb in scm_lazy_catch (key=0x97c, thunk=0x1, 
    handler=0x2b966026f8d0) at throw.c:545
#71 0x00002b965dfb125f in scm_deval (x=0x2b965da9b4d0, env=0x2b966026f800)
    at eval.c:3951
#72 0x00002b965dfb3ba2 in scm_dapply (proc=0x2b966026f700, arg1=0x97c, 
    args=0x2b966026f800) at eval.c:4619
#73 0x00002b965dfaf32d in scm_apply (proc=0x2b966026f720, arg1=0x97c, 
    args=0x97c) at eval.c:4407
#74 0x00002b965dfaea03 in scm_call_0 (proc=0x97c) at eval.c:4262
#75 0x00002b965dfec27d in scm_body_thunk (body_data=0x97c) at throw.c:316
#76 0x00002b965dfebfa2 in scm_internal_catch (tag=0x37c, 
    body=0x2b965dfec270 <scm_body_thunk>, body_data=0x7fff4d061a50, 
    handler=0x2b965dfec290 <scm_handle_by_proc>, handler_data=0x7fff4d061a48)
    at throw.c:172
#77 0x00002b965dfec58b in scm_catch (key=0x97c, thunk=0x1, 
    handler=0x2b966026f790) at throw.c:516
#78 0x00002b965dfb125f in scm_deval (x=0x2b965dab09a0, env=0x2b966026f670)
    at eval.c:3951
#79 0x00002b965dfb1c0d in scm_deval (x=0x2b966026f6b0, env=0x2b966026f670)
    at eval.c:3203
#80 0x00002b965dfb3ba2 in scm_dapply (proc=0x2b966026f580, arg1=0x97c, 
    args=0x2b966026f5f0) at eval.c:4619
#81 0x00002b965dfaf32d in scm_apply (proc=0x2b966026f5a0, arg1=0x97c, 
    args=0x97c) at eval.c:4407
#82 0x00002b965dfaea03 in scm_call_0 (proc=0x97c) at eval.c:4262
#83 0x00002b965dfa540a in scm_internal_dynamic_wind (
    before=0x525218 <scm_i_root_state_key>, inner=0x2b965dfae9f0 <scm_call_0>, 
    after=0x2b965df9e530 <decrease_block>, inner_data=0x2b966026f5a0, 
    guard_data=0x0) at dynwind.c:144
#84 0x00002b965df9e584 in scm_call_with_blocked_asyncs (proc=0x97c)
    at async.c:322
#85 0x00002b965dfb1344 in scm_deval (x=0x97c, env=0x2b966026f410)
    at eval.c:4095
#86 0x00002b965dfb1c0d in scm_deval (x=0x2b966026f130, env=0x2b9660270d00)
    at eval.c:3203
#87 0x00002b965dfb1c0d in scm_deval (x=0x2b9660270b10, env=0x2b9660270ad0)
    at eval.c:3203
#88 0x00002b965dfb3ba2 in scm_dapply (proc=0x2b96602700b0, arg1=0x97c, 
    args=0x2b9660270ad0) at eval.c:4619
#89 0x00002b965dfaf32d in scm_apply (proc=0x2b96602700d0, arg1=0x97c, 
    args=0x97c) at eval.c:4407
#90 0x00002b965dfaea03 in scm_call_0 (proc=0x97c) at eval.c:4262
#91 0x00002b965dfa52a3 in scm_dynamic_wind (in_guard=0x2b9660270080, 
    thunk=0x2b96602700d0, out_guard=0x2b9660270120) at dynwind.c:104
#92 0x00002b965dfad160 in scm_ceval (x=0x2b965daf5980, env=0x2b9660270030)
    at eval.c:3951
#93 0x00002b965dfb0454 in scm_i_eval_x (exp=0x97c, env=0x1) at eval.c:5398
#94 0x00002b965dfb04d5 in scm_primitive_eval_x (exp=0x2b965dace3b0)
    at eval.c:5415
#95 0x00002b965dfb05b9 in inner_eval_x (data=0x97c) at eval.c:5462
#96 0x00002b965dfa540a in scm_internal_dynamic_wind (
    before=0x525218 <scm_i_root_state_key>, 
    inner=0x2b965dfb05b0 <inner_eval_x>, 
    after=0x2b965dfb0570 <restore_environment>, inner_data=0x2b965dace3b0, 
    guard_data=0x2b965dace3a0) at dynwind.c:144

#97 0x00002b965dfb0621 in scm_eval_x (exp=0x2b965dace3b0, module=0x0)
    at eval.c:5471
#98 0x00002b965dfe077e in scm_shell (argc=1, argv=0x7fff4d062558)
    at script.c:672
#99 0x00002b965dfc5bd4 in invoke_main_func (body_data=0x0) at init.c:600
#100 0x00002b965dfc5b87 in scm_boot_guile_1 (base=0x97c, 
    closure=0x7fff4d062440) at init.c:580
#101 0x00002b965dfc5896 in scm_boot_guile (argc=2428, argv=0x1, main_func=0, 
    closure=0x0) at init.c:392
#102 0x0000000000403d90 in main (argc=2428, argv=0x1) at bcpnnx.cc:47

  reply	other threads:[~2008-07-01 10:14 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 [this message]
2008-07-01 12:27         ` Ludovic Courtès
2008-07-01 14:24           ` Roland Orre
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=1214907252.6032.130.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).