headers
Michal Maruška | 9 Jun 2006 03:36
Picon

segfault with threads


Hello Shiro and all, 

I have a kahua application, which segfaults iff I use threads.
The program uses custom C bindings, so I don't claim it's not a
bug in my code.  But the fault occurs always at the same
point (in gauche code), so maybe some hint would help me.

The fault is this:

[Switching to Thread -1212094784 (LWP 1321)]
0xb7df43b0 in run_loop () at vm.c:1126
1126                CASE(SCM_VM_LREF20) { VAL0 = ENV_DATA(ENV->up->up, 0);NEXT1; }
(gdb) bt
#0  0xb7df43b0 in run_loop () at vm.c:1126
#1  0xb7dfc698 in user_eval_inner (program=0x8c24580, codevec=0x80ead48) at vm.c:2919
#2  0x0804a3d1 in main (argc=11, argv=0xbf960a64) at main.c:425

The program uses 2 helper threads only at one point.
To trace down the problem I tried to run those threads serially.

Here is how I make the threads run serially:

(let1 t1 (load-people-list pg "f")
  (if (thread? t1)
      (thread-join! t1)))
(let1 t2 (load-people-list pg "m")
  (if (thread? t2)
      (thread-join! t2)))
(Continue reading)

Permalink | Reply | 2 comments |
headers
Shiro Kawai | 11 Jun 2006 03:17
Favicon

Re: segfault with threads

It's difficult to nail down the exact source of the problem
from given information, but the direct cause of segfault seems
to be the ENV pointer being screwed up.

Could you try to run gosh with '--fno-inline --fno-combine-instructions'
options?  It turns of almost all optimizations in VM.  If it
makes segfault disappear, a compiler bug is strongly suspected.

--shiro

From: mmc <at> maruska.dyndns.org (Michal Maruška)
Subject: [Gauche-devel] segfault with threads
Date: Fri, 09 Jun 2006 03:36:34 +0200

> 
> Hello Shiro and all, 
> 
> I have a kahua application, which segfaults iff I use threads.
> The program uses custom C bindings, so I don't claim it's not a
> bug in my code.  But the fault occurs always at the same
> point (in gauche code), so maybe some hint would help me.
> 
> 
> The fault is this:
> 
> [Switching to Thread -1212094784 (LWP 1321)]
> 0xb7df43b0 in run_loop () at vm.c:1126
> 1126                CASE(SCM_VM_LREF20) { VAL0 = ENV_DATA(ENV->up->up, 0);NEXT1; }
> (gdb) bt
> #0  0xb7df43b0 in run_loop () at vm.c:1126
(Continue reading)

Permalink | Reply | 1 comment |
headers
KOGURO, Naoki | 11 Jun 2006 11:26

c-wrapper 0.4.0

Hi all.

c-wrapper 0.4.0 is released.

The changes are:
- Add support for Intel Mac.
- Add support for Objective-C (MacOSX only).
- Fixed FFI for FreeBSD, you can use functions which return a struct  
or union.
- Pointer objects can have their own finalizers.
- Add the info document, but it's still incomplete.

Be careful to use a finalizer for a pointer object, because it can  
finalize an alive pointer in the below case.

; A and B are different pointer objects, but they point the same  
address.
(define A (ref some-struct-obj 'some-pointer))
(define B (ref some-struct-obj 'some-pointer))

; register finalizer to the pointer object A
(register-finalizer! A (lambda (ptr) (free ptr)))

(define A #f)
; The finalizer of A will be called in spite of B is alive.
(gc)

See http://homepage.mac.com/naoki.koguro/prog/c-wrapper/index.html  
for the changelog and more details.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Shiro Kawai | 11 Jun 2006 12:02
Favicon

Re: c-wrapper 0.4.0

Thank you for this nice tool, Naoki.

I'd like to add a word about finalizer.
To set up a finalizer properly is EXTREMELY tricky business.
That's why it is not yet exposed to Scheme level in Gauche.

The most important thing you have to keep in mind is that
the finalizers may not be called in 'natural order': suppose
you have an object A pointing an object B, both have finalizers,
and at a certain GC cycle both A and B became a garage.
There's no guarantee that A's finalizer is called before B's
finalizer---so, in A's finalizer, you have a pointer to B but
B can already be finalized!  You have to keep this in mind when
you write A's finalizer.
(The other trickiness is that you can't predict which thread
calls the finalizer).

I haven't come up with a better solution for this, but there 
may be some way to make it safer.  Before that, I tend to
to think not to allow full power of Scheme in finalizers.
So, if the resource management is the only concern, I'd rather
like to have an interface which registers "a pointer to free"
or something, instead of allowing arbitrary Scheme closure to
be registered.  It's just my gut feeling.  Maybe it's OK as
it is, if it is accomanied with flashing red WARNING statement
in the manual describing dangers of finalizers.

(BTW, I'm not sure whether it fits to c-wrapper or not, but
Gauche's ScmForeignPointer class has an option to take care of
this pointer aliasing problem; see the comments around
(Continue reading)

Permalink | Reply | 1 comment |
headers
KOGURO, Naoki | 11 Jun 2006 13:53

Re: c-wrapper 0.4.0

Thank you very much for your quick and instructive reply.

Originally, I intend to use the finalizer with Objective-C reference  
counter.

(define (get-data obj)
   (let ((data (ref obj 'some-pointer)))
      [data 'retain]
      (register-finalizer! data (lambda (ptr) [ptr 'release]))
      data))

The problems about the finalizer could be avoid in this case.

On 2006/06/11, at 19:02, Shiro Kawai wrote:

> (BTW, I'm not sure whether it fits to c-wrapper or not, but
> Gauche's ScmForeignPointer class has an option to take care of
> this pointer aliasing problem; see the comments around
> SCM_FOREIGN_POINTER_KEEP_IDENTITY in gauche.h)

Yes, SCM_FOREIGN_POINTER_KEEP_IDENTITY may solve the aliasing problem  
in general case. I would change the code about <c-ptr> to use  
ScmForeignPointer in future release.

But the finalizer would be still dangerous if it had be solved. I've  
questioned myself to add support finalizer or not, in fact.

--
KOGURO, Naoki <naoki <at> koguro.net>
(Continue reading)

Permalink | Reply | 0 comments |
headers
KIMURA Shigenobu | 19 Jun 2006 03:04
Picon

SRFI-34

Gauche's guard shows different behavior than SRFI-34's
reference implementation.

Is this intentional or bug?

I like srfi-34's behavior because its more intuitive for me.

-- skimu

$ cat fo.scm
(define-syntax srfi-34/guard
   (syntax-rules ()
     ((guard (var clause ...) e1 e2 ...)
      ((call-with-current-continuation
        (lambda (guard-k)
          (with-exception-handler
           (lambda (condition)
             ((call-with-current-continuation
                (lambda (handler-k)
                  (guard-k
                   (lambda ()
                     (let ((var condition))      ; clauses may SET! var
                       (guard-aux (handler-k (lambda ()
                                               (raise condition)))
                                  clause ...))))))))
           (lambda ()
             (call-with-values
              (lambda () e1 e2 ...)
              (lambda args
                (guard-k (lambda ()
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shiro Kawai | 20 Jun 2006 06:59
Favicon

Re: SRFI-34

From: KIMURA Shigenobu <skimu <at> mac.com>
Subject: [Gauche-devel] SRFI-34
Date: Sun, 18 Jun 2006 20:04:49 -0500

> Gauche's guard shows different behavior than SRFI-34's
> reference implementation.
> 
> Is this intentional or bug?
> 
> I like srfi-34's behavior because its more intuitive for me.

That's a bug.  I misunderstood srfi-34's description.

--shiro
Permalink | Reply | 0 comments |

Gmane