stumped by scm_car/scm_cdr

stumped by scm_car/scm_cdr

[Han-Wen Nienhuys]

I have a problem that I cannot make heads of tails from.

If I go through the entire LilyPond C++ source, and replace

   ly_car

defined as 

	 inline SCM ly_car (SCM x) { return SCM_CAR (x); }

by

	scm_car

and do the same for scm_cdr(), then my LilyPond mysteriously hangs in

	(gdb) r input/example-1
	[Thread debugging using libthread_db enabled]
	[New Thread 1075224992 (LWP 13675)]

	Now processing `input/example-1.ly'
	Parsing...

	Program received signal SIGINT, Interrupt.
	[Switching to Thread 1075224992 (LWP 13675)]
	0xffffe410 in ?? ()
	(gdb) bt
	#0  0xffffe410 in ?? ()
	#1  0xbfffa058 in ?? ()
	#2  0x00000002 in ?? ()
	#3  0x43afa18e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
	(gdb) 


this seemingly happens at a random place, and I can't investigate by
setting a breakpoint on __lll_mutex_lock_wait (If I try, the run
inside GDB succeeds as normal.)

What could be going on here?


-- 
 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



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

Re: stumped by scm_car/scm_cdr

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> I have a problem that I cannot make heads of tails from.
> [...]
> What could be going on here?

Tough.  In case you didn't try this already, I would recompile Guile
and LilyPond without optimization (CFLAGS="-g").  That should give
better GDB output.  Hopefully the bug wont disappear by that...

Do you use threads in the example?  From what context is
_lll_mutex_lock_wait being called?

-- 
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: stumped by scm_car/scm_cdr

[Han-Wen Nienhuys]

mvo@zagadka.de writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
> > I have a problem that I cannot make heads of tails from.
> > [...]
> > What could be going on here?
> 
> Tough.  In case you didn't try this already, I would recompile Guile
> and LilyPond without optimization (CFLAGS="-g").  That should give
> better GDB output.  Hopefully the bug wont disappear by that...
> 
> Do you use threads in the example?

No.

> From what context is
> _lll_mutex_lock_wait being called?

I tried setting a breakpoint on this function, but if I do, the run
completes as expected normally.

-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



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

Re: stumped by scm_car/scm_cdr

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> I tried setting a breakpoint on this function, but if I do, the run
> completes as expected normally.

One more idea: it might be that you (harmlessly) used SCM_CAR or
SCM_CDR on a non-pair but scm_car/scm_cdr are now complaining about
this by throwing an error.  That error might happen in a context where
throwing does not work, or might lead to endless recursion, or some
other anomaly.  Try replacing the call to scm_wrong_type_arg_msg in
scm_car and scm_cdr with a simple abort.

(This does not explain why the bug disappears when debugging it, so it
is an unlikely scenario...  Typical case of a Heisenbug...)


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

Re: stumped by scm_car/scm_cdr

[Han-Wen Nienhuys]

marius.vollmer@uni-dortmund.de writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
> > I tried setting a breakpoint on this function, but if I do, the run
> > completes as expected normally.
> 
> One more idea: it might be that you (harmlessly) used SCM_CAR or
> SCM_CDR on a non-pair but scm_car/scm_cdr are now complaining about
> this by throwing an error.  That error might happen in a context where
> throwing does not work, or might lead to endless recursion, or some
> other anomaly.  Try replacing the call to scm_wrong_type_arg_msg in
> scm_car and scm_cdr with a simple abort.

I tried to remove all fishy looking places where SCM_C[AD]R were used,
and now it seems to work OK. You might want to consider just doing
abort() or a something similar as a standard. If the C code uses the
API incorrectly, then (IMO) this is not something that should be
signaled at Scheme level using scm_error(), because no amount of
Scheme coding can fixup such errors.

-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



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

Re: stumped by scm_car/scm_cdr

[Han-Wen Nienhuys]

hanwen@xs4all.nl writes:
> > One more idea: it might be that you (harmlessly) used SCM_CAR or
> > SCM_CDR on a non-pair but scm_car/scm_cdr are now complaining about
> > this by throwing an error.  That error might happen in a context where
> > throwing does not work, or might lead to endless recursion, or some
> > other anomaly.  Try replacing the call to scm_wrong_type_arg_msg in
> > scm_car and scm_cdr with a simple abort.
> 
> I tried to remove all fishy looking places where SCM_C[AD]R were used,
> and now it seems to work OK. You might want to consider just doing
> abort() or a something similar as a standard. If the C code uses the
> API incorrectly, then (IMO) this is not something that should be
> signaled at Scheme level using scm_error(), because no amount of
> Scheme coding can fixup such errors.

for the record, these fishy places were mostly in GC mark functions,
where I did

  smobbed_type * p = (smobbed_type*) SCM_CDR(scm) 

iso.

  smobbed_type * p = (smobbed_type*) SCM_GC_CELL_WORD1(scm) 


-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



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

Re: stumped by scm_car/scm_cdr

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> for the record, these fishy places were mostly in GC mark functions,
> where I did
>
>   smobbed_type * p = (smobbed_type*) SCM_CDR(scm) 

Ahh yes, this can not be replaced with scm_cdr.  The Right Thing to
use here is SCM_SMOB_DATA as in

    smobbed_type * p = (smobbed_type*) SCM_SMOB_DATA (scm);

The manual should make this clear now.

-- 
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: stumped by scm_car/scm_cdr

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> I tried to remove all fishy looking places where SCM_C[AD]R were used,
> and now it seems to work OK. You might want to consider just doing
> abort() or a something similar as a standard.

That would not fit SCM_CAR, SCM_CDR etc well.  These macros are there
for code that knows what it does and wants to do it fast.  You can use
SCM_DEBUG_CELL_ACCESSES to have them do some checks, however.  These
checks will only assert that you access a cell, not whether that cell
represents a pair.

In general Guile only aborts when there is no other way, for example
when it has run out of memory or when the error reporting mechanism
itself fails.

> If the C code uses the API incorrectly, then (IMO) this is not
> something that should be signaled at Scheme level using scm_error(),
> because no amount of Scheme coding can fixup such errors.

It is not really clear to me what "incorrect use of the C API" would
mean; we can not really talk about it in general, only about specific
cases.

For example, when scm_error is called during GC that is a fatal error
since scm_error is not allowed to return but it can't do its usual
thing and throw to a handler in the middle of GC.  People are just not
supposed to do anything during GC that can signal an error, so Guile
just aborts in this case.

However, when scm_to_locale_string is asked to convert a string that
contains a #\nul character, it signals an error.  Why shouldn't it?

So, we might talk about whether SCM_CAR and SCM_CDR should abort when
passed a non-pair, or whether they should signal an error; or whether
they should check that they are passed a cell.

-- 
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: stumped by scm_car/scm_cdr

[Han-Wen Nienhuys]

mvo@zagadka.de writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
> > I tried to remove all fishy looking places where SCM_C[AD]R were used,
> > and now it seems to work OK. You might want to consider just doing
> > abort() or a something similar as a standard.
> 
> That would not fit SCM_CAR, SCM_CDR etc well.  These macros are there
> for code that knows what it does and wants to do it fast.  You can use
> SCM_DEBUG_CELL_ACCESSES to have them do some checks, however.  These
> checks will only assert that you access a cell, not whether that cell
> represents a pair.
> 
> In general Guile only aborts when there is no other way, for example
> when it has run out of memory or when the error reporting mechanism
> itself fails.

Ok. In that case, we should figure out why this could hang.

One thing that is fishy, is the fact that  

	void
	scm_wrong_type_arg_msg 

tries to call scm_list_2(), which will fail if GC is active.

I've added a check to scm_cell/scm_double_cell that calls abort() if
GC is running.

> So, we might talk about whether SCM_CAR and SCM_CDR should abort when
> passed a non-pair, or whether they should signal an error; or whether
> they should check that they are passed a cell.

No, I just don't want GUILE to ever hang. An error, ungraceful or not,
is always preferable. This probably fixes the cause, but wouldn't it
be better to check the thread handling as well? I guess that calling
scm_cell from GC causes a problem, because GC will (again) put all
threads to sleep.


-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



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

Re: stumped by scm_car/scm_cdr

[Han-Wen Nienhuys]

hanwen@xs4all.nl writes:
> tries to call scm_list_2(), which will fail if GC is active.
> 
> I've added a check to scm_cell/scm_double_cell that calls abort() if
> GC is running.

addendum: this causes a crash, since gc.c says

  scm_c_hook_run (&scm_after_gc_c_hook, 0);
  --scm_gc_running_p;

is there any significance in the ordering here? The problem
is that many scm_after_gc_c_hooks construct lists, which uses
scm_cell, obviously. 

-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



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

Re: stumped by scm_car/scm_cdr

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> I've added a check to scm_cell/scm_double_cell that calls abort() if
> GC is running.

Well, OK.  Another idea is to set the freelists to NULL during GC
explicitely, thus causing scm_cell etc to call scm_gc_for_newcell
immediately, and scm_gc_for_newcell could then check whether the GC is
already running.  That would not make scm_cell etc slower for the
usual case that the GC is in fact not running.  Could you try that
variant?


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

Re: stumped by scm_car/scm_cdr

[Han-Wen Nienhuys]

marius.vollmer@uni-dortmund.de writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
> > I've added a check to scm_cell/scm_double_cell that calls abort() if
> > GC is running.
> 
> Well, OK.  Another idea is to set the freelists to NULL during GC
> explicitely, thus causing scm_cell etc to call scm_gc_for_newcell
> immediately, and scm_gc_for_newcell could then check whether the GC is
> already running.  That would not make scm_cell etc slower for the
> usual case that the GC is in fact not running.  Could you try that
> variant?

I tried to look at this, but scm_i_freelist is now a thread-specific
variable. I'm unsure if and how they should all be set to null or
SCM_EOL.


-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



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

Re: stumped by scm_car/scm_cdr

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> marius.vollmer@uni-dortmund.de writes:
>> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>> 
>> > I've added a check to scm_cell/scm_double_cell that calls abort() if
>> > GC is running.
>> 
>> Well, OK.  Another idea is to set the freelists to NULL during GC
>> explicitely, thus causing scm_cell etc to call scm_gc_for_newcell
>> immediately, and scm_gc_for_newcell could then check whether the GC is
>> already running.  That would not make scm_cell etc slower for the
>> usual case that the GC is in fact not running.  Could you try that
>> variant?
>
> I tried to look at this, but scm_i_freelist is now a thread-specific
> variable. I'm unsure if and how they should all be set to null or
> SCM_EOL.

Only the scm_i_freelist of the thread actually doing the garbage
collection needs to be set, I think.  All other threads are stopped at
that time and can't allocate storage.


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

Re: stumped by scm_car/scm_cdr

[Dirk Herrmann]

Marius Vollmer wrote:

>  Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> > tried to remove all fishy looking places where SCM_C[AD]R were
> > used, and now it seems to work OK. You might want to consider just
> > doing abort() or a something similar as a standard.
>
>  That would not fit SCM_CAR, SCM_CDR etc well. These macros are there
>  for code that knows what it does and wants to do it fast. You can
>  use SCM_DEBUG_CELL_ACCESSES to have them do some checks, however.
>  These checks will only assert that you access a cell, not whether
>  that cell represents a pair.

Better use SCM_DEBUG_PAIR_ACCESSES, which does exactly the right thing 
here: It checks whether SCM_CAR etc. are really applied to a pair.

Best regards
Dirk Herrmann



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