[Fluxus] strange crash

[krgn]

hey again (and sorry for the noise!) but I just realised that the problem
only occurs when using the default 'buffer' with the CLI-like  prompt. If I
switch to another buffer with Ctrl-1 makes fluxus-0.15 run smoothly. I
attached another valgrind log where I added the option --leak-check=full and
--show-reachable=yes maybe that helps...

g'nite :)

k

On Tue, Mar 18, 2008 at 10:18 PM, krgn <k.gebbert at gmail.com> wrote:

> I used valgrind with it (honestly not knowing too much about it ;)). the
> log is attached. to me it looks as if it could be a bug...  but hey.. :] I
> wouldn't know
>
> k
>
>
> On Tue, Mar 18, 2008 at 10:09 PM, krgn <k.gebbert at gmail.com> wrote:
>
> > Hey ppl,
> >
> > I am experiencing a strange crash with fluxus-0.15 checked out from cvs.
> > I tried to get a backtrace with gdb but got this:
> >
> > krgn at softmachine:~/dev/fluxus$ gdb fluxus-0.15
> > GNU gdb 6.6-debian
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> > are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > This GDB was configured as "i486-linux-gnu"...
> > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
> > (gdb) run
> > Starting program: /usr/local/bin/fluxus-0.15
> > [Thread debugging using libthread_db enabled]
> > [New Thread -1218312512 (LWP 10117)]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread -1218312512 (LWP 10117)]
> > get_bucket (table=0xb7400e70, key=0xb750a628 "0", add=1, b=0x0) at
> > xsrc/hash.c:682
> > 682     xsrc/hash.c: No such file or directory.
> >         in xsrc/hash.c
> > Current language:  auto; currently c
> > (gdb)
> >
> >
> >
> > mzscheme is at the latest stable version, 372 I believe. anyone got a
> > clue or similar problems? the crash usually happens quite immediately after
> > starting the binary, not even having finished entering some code. one thing
> > that I notices is this in the terminal, when evaluating valid code:
> >
> > 20#f::23: read: expected a character after #\
> > #f::31: read: expected a character after #\
> >
> >
> > greetings, k
> >
> > ps: if you are in need for more info, let me know!
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20080318/93be89a7/attachment.html>