With Guile 1.8.1 but works with .0 too:
$ guile
> (close (current-error-port))
#t
> (close (current-input-port))
#t
-> segmentation fault
The stack trace shows a lot of recursive calls to
scm_gc_mark and scm_gc_mark_dependencies with the fault
happening at line 303 of gc-mark.c.
$ guile
> (clos
Bill Schottstaedt <[EMAIL PROTECTED]> writes:
> In Friday's CVS guile there are two redundant declarations.
Fixed, thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail
> Please try again, I think I have fixed it:
The backtrace problem seems to be fixed -- thanks!
In Friday's CVS guile there are two redundant declarations.
In gc.h (line 273):
SCM_API unsigned long scm_gc_cells_collected;
SCM_API unsigned long scm_gc_cells_collected;
net_db.h: SCM_API SCM scm_get
> "Han-Wen" == Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
Han-Wen> Yeah, I found out so far. Now I have to figure out what in my 1
Han-Wen> lines of Scheme code is causing
Han-Wen>ERROR: In procedure car:
Han-Wen>ERROR: Wrong type argument in position 1: ()
Sure
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> It seems to be working. There was a stray variable in eval.c, though.
> I fixed that.
Yep, thanks.
> BTW, how is GUILE 1.8 progressing?
The two big things that need to be done are: GH replacement (including
docs of course) and finishing the thread
[EMAIL PROTECTED] writes:
> Please try again, I think I have fixed it:
Thanks for your quick reply.
It seems to be working. There was a stray variable in eval.c, though.
I fixed that.
BTW, how is GUILE 1.8 progressing? Have you considered switching to a
time-based release schedule, like GNO
Bill Schottstaedt <[EMAIL PROTECTED]> writes:
> > 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> > (gdb) bt
> > #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
>
> I've hit this so many times I've stopped using the CVS Guile -- there's
> definite
Han-Wen Nienhuys wrote:
[EMAIL PROTECTED] writes:
[Switching to Thread 1074493760 (LWP 27557)]
0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
(gdb) bt
#0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
#1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, e
[EMAIL PROTECTED] writes:
> > [Switching to Thread 1074493760 (LWP 27557)]
> > 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> > (gdb) bt
> > #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> > #1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, env=0x405
> 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> (gdb) bt
> #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
I've hit this so many times I've stopped using the CVS Guile -- there's
definitely a bug tickled by backtrace, but I haven't had time to try t
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> elapsed time: 0.01 secondsBacktrace:
> In c.ly:
>2: 0* [determine-split-list #(# # # # ...) #(# # # #)]
> In unknown file:
>?: 1
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1074493760 (LWP 27557)]
> 0x4002
hi,
I have a nasty coredump; this is with fairly recent CVS (ChangeLog
timestamp 26/12). Any thoughts? This is from within LilyPond. The
only funky thing was that the file was doing some operations with a
trivial GOOPS class. Any ideas?
elapsed time: 0.01 secondsBacktrace:
In c.ly:
2
On Mon, 23 Jul 2001, Ping Zhou wrote:
> Recently I met a serious problem on 64bit machine. I am using guile1.0.
Is that correct? You are using guile Version 1.0 ? In that case, I am
afraid, people on this list probably won't be able to help you. That
release is several years old. The current
Hi all,
Recently I met a serious problem on 64bit machine. I am using guile1.0.
In scm_gc_mark of gc.c:
if (len)
{
for (x = 0; x < len - 2; x += 2, ++mem)
if (fields_desc[x] == 'p')
scm_gc_mark (*mem);
Michael Livshin writes ...
> Matthew R Wette <[EMAIL PROTECTED]> writes:
>
> > One more piece of information. I gdb'd a core dump and
> > it crashes at line 1407 in gc.c:
> > m += free (vtable_data, (scm_bits_t *) SCM...
> > Here the variable &qu
Matthew R Wette <[EMAIL PROTECTED]> writes:
> One more piece of information. I gdb'd a core dump and
> it crashes at line 1407 in gc.c:
> m += free (vtable_data, (scm_bits_t *) SCM...
> Here the variable "free" is 0.
hrm. looks like scrambled bytes.
ks for your bug report,
> Dirk
One more piece of information. I gdb'd a core dump and
it crashes at line 1407 in gc.c:
m += free (vtable_data, (scm_bits_t *) SCM...
Here the variable "free" is 0.
Matt
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
On Wed, 22 Nov 2000, Matt Wette wrote:
> If I start up guile and load some code it seems to run OK.
> If I load the code a second time, it core-dumps. Here is
> the gdb output. If you have any clues on this one I'd
> appreciate it. -- thanks, Matt
Sorry, but we can't tell you much about it wi
If I start up guile and load some code it seems to run OK.
If I load the code a second time, it core-dumps. Here is
the gdb output. If you have any clues on this one I'd
appreciate it. -- thanks, Matt
guile version is 1.4
head of config.status is
# ./configure --prefix=/opt/guile --with-mo
19 matches
Mail list logo
