[resending -- this time to the list. Sorry for the noise.]
On Thu, Apr 28, 2011 at 7:55 PM, Andy Wingo <wi...@pobox.com> wrote:
> Hi Andrew,
>
> On Thu 28 Apr 2011 17:33, Andrew Gaylard <a...@computer.org> writes:
>
>> With the attached patch, I can build and run guile-1.8.8 on Solaris.
>> It seems that the old logic that used USRSTACK no longer works,
>> so I took it out.
>>
>> Tested on Solaris 10u9, on both SPARC64 and x86_64.
>
> Thanks for the patch. Do you have access to other versions of Solaris?
> We would need to test this patch under them as well.
>
> Andy
Hi Andy,
I've tested on a Solaris-9 SPARC zone, with these results:
gmake[4]: Entering directory
`/export/home/andrewg/guile/branches/1.8.8/src/guile-1.8.8/test-suite/standalone'
PASS: test-system-cmds
PASS: test-require-extension
PASS: test-bad-identifiers
PASS: test-num2integral
PASS: test-round
PASS: test-gh
PASS: test-asmobs
PASS: test-list
FAIL: test-unwind
PASS: test-conversion
PASS: test-fast-slot-ref
PASS: test-use-srfi
PASS: test-scm-c-read
PASS: test-scm-take-locale-symbol
PASS: test-with-guile-module
PASS: test-scm-with-guile
==================================
1 of 16 tests failed
Please report to bug-gu...@gnu.org
==================================
This occurs with and without the patch to guile-1.8.8/libguile/threads.c.
Without the patch to guile-1.8.8/libguile/gc_os_dep.c, the build doesn't
even complete:
gc_os_dep.c: In function `scm_get_stack_base':
gc_os_dep.c:1909: error: `USERLIMIT' undeclared (first use in this function)
gc_os_dep.c:1909: error: (Each undeclared identifier is reported only once
gc_os_dep.c:1909: error: for each function it appears in.)
So this patch is good to go, I think.
I've tried debugging the core left behind by test-unwind by rebuilding with -g,
but I get this far, after which I'm stuck:
Core was generated by
`/export/home/andrewg/guile/branches/1.8.8/src/guile-1.8.8/test-suite/standalone'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f8bf714 in scm_i_dowinds (to=0xfd740, delta=-1,
turn_func=0x7f8b6764 <copy_stack>, data=0xffbfec10) at dynwind.c:303
303 if (FRAME_P (wind_elt))
(gdb) bt
#0 0x7f8bf714 in scm_i_dowinds (to=0xfd740, delta=-1,
turn_func=0x7f8b6764 <copy_stack>, data=0xffbfec10) at dynwind.c:303
#1 0x7f8bf6f0 in scm_i_dowinds (to=0xfd750, delta=-2,
turn_func=0x7f8b6764 <copy_stack>, data=0xffbfec10) at dynwind.c:300
#2 0x7f8b6854 in copy_stack_and_call (continuation=0x105668, val=0x4,
dst=0xffbfeec4) at continuations.c:222
#3 0x7f8b698c in scm_dynthrow (cont=0xfd758, val=0x4) at continuations.c:275
#4 0x7f8b6758 in grow_stack (cont=0x7f9bb6c4, val=0xffbfefd0) at
continuations.c:187
#5 0x7f8b6974 in scm_dynthrow (cont=0x0, val=0x0) at continuations.c:271
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) list
298 SCM wind_key;
299
300 scm_i_dowinds (SCM_CDR (to), 1 + delta, turn_func, data);
301 wind_elt = SCM_CAR (to);
302
303 if (FRAME_P (wind_elt))
304 {
305 if (!FRAME_REWINDABLE_P (wind_elt))
306 scm_misc_error ("dowinds",
307 "cannot invoke continuation from
this context",
(gdb) p wind_elt
$1 = (SCM) 0x0
(gdb) p to
$2 = (SCM) 0xfd740
I'm pretty sure this is not due to the patch to guile-1.8.8/libguile/threads.c,
since it happens with and without it.
--
Andrew
