Re: built with SCM_DEBUG=1 lately?

Re: built with SCM_DEBUG=1 lately?

[Ken Raeburn]

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


(BTW, I should've mentioned in my earlier mail tonight that the patch
got me past compilation failures on Linux; my original report
complaining of some format string problems was on a Mac laptop, where
I haven't tried the build again.)

>From the comments, it looks like the list returned by scm_i_dynwinds
can have both cons cells and smob objects in it, like the winder
object that was keeping the snarf step from working for me.

This patch causes the SCM_CDAR invocation to be applied only if the
SCM_CAR is a pair.

BTW, under SCM_DEBUG=1 it'd be nice if SCM_SMOB_OBJECT*,
SCM_SMOB_DATA*, etc, would check that the passed object is a smob.  I
don't think that's happening.

Ken


2005-07-01  Ken Raeburn  <raeburn@raeburn.org>

	* throw.c (scm_ithrow): Only use SCM_CDAR if SCM_CAR is known to
	be a cons cell.


[-- Attachment #2: patch for throw.c to not run SCM_CDR on non-pairs --]
[-- Type: application/octet-stream, Size: 609 bytes --]

Index: throw.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/throw.c,v
retrieving revision 1.107
diff -p -u -r1.107 throw.c
--- throw.c	23 May 2005 19:57:21 -0000	1.107
+++ throw.c	1 Jul 2005 06:41:31 -0000
@@ -623,7 +623,8 @@ scm_ithrow (SCM key, SCM args, int noret
   jmpbuf = SCM_CDR (dynpair);
   
   for (wind_goal = scm_i_dynwinds ();
-       !scm_is_eq (SCM_CDAR (wind_goal), jmpbuf);
+       !(scm_is_pair (SCM_CAR (wind_goal))
+	 && scm_is_eq (SCM_CDAR (wind_goal), jmpbuf));
        wind_goal = SCM_CDR (wind_goal))
     ;
 

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

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

Re: built with SCM_DEBUG=1 lately?

[Kevin Ryde]

Ken Raeburn <raeburn@raeburn.org> writes:
>
> From the comments, it looks like the list returned by scm_i_dynwinds
> can have both cons cells and smob objects in it, like the winder
> object that was keeping the snarf step from working for me.

Yep that happens for me too, though it seems to have been non-fatal
(in a non-debug build).  Dunno what's meant to happen though.


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

Re: built with SCM_DEBUG=1 lately?

[Ken Raeburn]

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


The attached patch allows me to compile after configuring with
CPPFLAGS=-DSCM_DEBUG.  The build still dies in the snarf phase, as I
described a few days ago.

Ken


2005-07-01  Ken Raeburn  <raeburn@raeburn.org>

	* eval.c (s_scm_dbg_make_iloc): Fix spelling of SCM_IFRAMEMAX and
	SCM_IDISTMAX.  Cast scm_to_unsigned_integer result down to
	scm_t_bits.

	* pairs.c (scm_error_pair_access): Use scm_from_locale_string
	instead of the discouraged scm_makfrom0str.


[-- Attachment #2: guile patch for SCM_DEBUG=1 compilation --]
[-- Type: application/octet-stream, Size: 1344 bytes --]

Index: eval.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/eval.c,v
retrieving revision 1.397
diff -p -u -r1.397 eval.c
--- eval.c	6 Jun 2005 18:49:55 -0000	1.397
+++ eval.c	1 Jul 2005 06:09:59 -0000
@@ -372,8 +372,8 @@ SCM_DEFINE (scm_dbg_make_iloc, "dbg-make
 	    "offset @var{binding} and the cdr flag @var{cdrp}.")
 #define FUNC_NAME s_scm_dbg_make_iloc
 {
-  return SCM_MAKE_ILOC (scm_to_unsigned_integer (frame, 0, SCM_IFRAME_MAX),
-			scm_to_unsigned_integer (binding, 0, SCM_IDIST_MAX),
+  return SCM_MAKE_ILOC ((scm_t_bits) scm_to_unsigned_integer (frame, 0, SCM_IFRAMEMAX),
+			(scm_t_bits) scm_to_unsigned_integer (binding, 0, SCM_IDISTMAX),
 			scm_is_true (cdrp));
 }
 #undef FUNC_NAME
Index: pairs.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/pairs.c,v
retrieving revision 1.37
diff -p -u -r1.37 pairs.c
--- pairs.c	23 May 2005 19:57:21 -0000	1.37
+++ pairs.c	1 Jul 2005 06:09:59 -0000
@@ -36,7 +36,7 @@
 void scm_error_pair_access (SCM non_pair)
 {
   static unsigned int running = 0;
-  SCM message = scm_makfrom0str ("Non-pair accessed with SCM_C[AD]R: `~S´\n");
+  SCM message = scm_from_locale_string ("Non-pair accessed with SCM_C[AD]R: `~S´\n");
 
   if (!running)
     {

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

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

Re: built with SCM_DEBUG=1 lately?

[Kevin Ryde]

Ken Raeburn <raeburn@raeburn.org> writes:
>
> The attached patch allows me to compile after configuring with
> CPPFLAGS=-DSCM_DEBUG.

Thanks, I applied that.


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

built with SCM_DEBUG=1 lately?

[Ken Raeburn]

I was running into some problems with free() reporting unaligned 
pointers on my mac laptop, and decided to try switching on more 
debugging options.  I tried building with SCM_DEBUG=1, and several 
files needed tweaking.  Mostly in minor ways, due to -Werror -- %d for 
long values, stuff like that.  I'll send out a patch soon.

But after I got guile building again, it died with this error in the 
snarf step (first message is my added instrumentation).

../../source/libguile/throw.c:626: non-pair accessed with SCM_CDR: 
x=312960 x->car=50d7f
Non-pair accessed with SCM_C[AD]R: `#<winder 312960>?

   for (wind_goal = scm_i_dynwinds ();
        !scm_is_eq (SCM_CDAR (wind_goal), jmpbuf);    <<<----
        wind_goal = SCM_CDR (wind_goal))
     ;

So it's got a cons cell, but the car of the cons cell is not a plain 
cons cell but a "winder" smob object.  Perhaps the equivalent of 
WINDER_PROC or WINDER_DATA is what's desired here?

Ken


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