Segmentation fault in CVS

Segmentation fault in CVS

[Neil Jerram]

I'm seeing a failure of the test-system-cmds test, and have narrowed
it down to this:

neil@laruns:~/guile-cvs-head/guile/guile-core$ ./pre-inst-guile -q
guile> (exit 42)
Segmentation fault

      Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Segmentation fault in CVS

[Neil Jerram]

Bruce Korb <bkorb@gnu.org> writes:

> Neil Jerram wrote:
>> I'm seeing a failure of the test-system-cmds test, and have narrowed
>> it down to this:
>> neil@laruns:~/guile-cvs-head/guile/guile-core$ ./pre-inst-guile -q
>> guile> (exit 42)
>> Segmentation fault
>
> Marius was saying something about returning NULL in some path back
> to one of the entry functions.  If he really meant NULL and not 0,
> then he was talking about some sort of pointer that is taking on the
> value of 42?  Dunno....I do bet it is related.  :(  Cheers - Bruce

Perhaps, yes.  According to GDB the backtrace at the crash is

(gdb) bt
#0  0x401867f1 in pthread_mutex_lock () from /lib/tls/libpthread.so.0
#1  0x400b6a6b in scm_i_thread_put_to_sleep () at threads.c:1538
#2  0x4009a83f in scm_i_string_writable_chars (orig_str=0x5b) at strings.c:352
#3  0x4009b02d in scm_c_string_set_x (str=0x405c3d00, p=0, chr=0x34)
    at strings.c:669
#4  0x40090485 in scm_read_token (ic=52, tok_buf=0xbfffe468, port=0x403ddc58, 
    weird=0) at read.c:700
#5  0x4008fff1 in scm_lreadr (tok_buf=0xbfffe468, port=0x403ddc58, 
    copy=0xbfffe46c) at read.c:642

and the problem appears to be that all_threads->next_thread has become
invalid:

(gdb) p *all_threads
$9 = {next_thread = 0xffffffff, handle = 0x405217f8, pthread = 1089387440, 
  join_queue = 0x405217e0, result = 0x4, exited = 0, sleep_object = 0x4, 
  sleep_mutex = 0x0, sleep_cond = {__c_lock = {__status = 0, __spinlock = 0}, 
  ...}...}

I'm not sure that's the real problem though, could just be an artefact
of stack corruption.  I tried breaking at the point (guilify_self_1)
where all_threads->next_thread is initialized correctly, and then
setting a watchpoint on all_threads->next_thread, but the watchpoint
didn't fire and the segmentation fault still occurred.

Regards,
        Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Segmentation fault in CVS

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I'm seeing a failure of the test-system-cmds test, and have narrowed
> it down to this:
>
> neil@laruns:~/guile-cvs-head/guile/guile-core$ ./pre-inst-guile -q
> guile> (exit 42)
> Segmentation fault
>
>       Neil

I think I've nailed this.  In this line in scmsigs.c ...

  read_without_guile_data *data = (read_without_guile_data *)data;

... the second "data" should be "raw_data".

Just checking, then will be in CVS shortly.

     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Segmentation fault in CVS

[Andy Wingo]

Hi,

On Tue, 2005-12-13 at 23:58 +0000, Neil Jerram wrote:
>   read_without_guile_data *data = (read_without_guile_data *)data;

Didn't fix the issue for me, same symptoms. Can't run pre-inst-guile; it
gives me:

(pygst gst) wingo@videoscale:~/src/guile/guile-core$ ./pre-inst-guile
ERROR: In procedure memoization:
ERROR: Bad binding #<freed cell 0x2aaaabc6de30; GC missed a reference>
in expression [...]

Regards,
-- 
Andy Wingo
http://wingolog.org/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Segmentation fault in CVS

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

>   read_without_guile_data *data = (read_without_guile_data *)data;
>
> ... the second "data" should be "raw_data".

Aaarghhhh! :-/   (This wouldn't happen with 'let'...)

Thanks for finding this.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Segmentation fault in CVS

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi,
>
> On Tue, 2005-12-13 at 23:58 +0000, Neil Jerram wrote:
>>   read_without_guile_data *data = (read_without_guile_data *)data;
>
> Didn't fix the issue for me, same symptoms. Can't run pre-inst-guile; it
> gives me:
>
> (pygst gst) wingo@videoscale:~/src/guile/guile-core$ ./pre-inst-guile
> ERROR: In procedure memoization:
> ERROR: Bad binding #<freed cell 0x2aaaabc6de30; GC missed a reference>
> in expression [...]

Well this obviously looks like a GC problem, and it's always tricky to
know where to start when debugging such problems.

It might help to know what the freed cell was before the GC set its
car to scm_tc_free_cell.  Do you get the same freed cell address
repeatedly?  If so, you can add code to print out the cell just before
the places that set its car (i.e. gc-card.c lines 258 and 292),
something like:

  if (SCM_UNPACK (scmptr) == 0x2aaaabc6de30)
  {
     scm_write (scmptr, SCM_UNDEFINED);
     scm_newline (SCM_UNDEFINED);
  }

Otherwise, it just occurred to me to wonder more about why we need the
fix from Ludovic that I applied a few days ago.  Why is there a window
between the creation of a GC card and its being initialized by
scm_i_init_card_freelist?  Given that there is a window, can a cell be
allocated from the card before scm_i_init_card_freelist is called?  If
it can, that would explain this bug, before scm_i_init_card_freelist
unconditionally sets all cells' car to scm_tc_free_cell.

That's as far as I can get for tonight.

       Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel