From: Aleksej S. <as...@in...> - 2009-03-17 21:49:36
|
Hello! I have problem on FreeBSD 6.3-STABLE i386: cc -I/home/asau/pkg/include -I/usr/include -Igllib -O2 -I/home/asau/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -c spvw.c spvw.d: In function `init_multithread': spvw.d:629: error: `PTHREAD_MUTEX_RECURSIVE_NP' undeclared (first use in this function) spvw.d:629: error: (Each undeclared identifier is reported only once spvw.d:629: error: for each function it appears in.) *** Error code 1 Stop. What is strange (a bit), that I don't have it on NetBSD. -- BECHA... CKOPO CE3OH... |
From: Vladimir T. <vtz...@gm...> - 2009-03-17 22:08:57
|
Hi, On Tue, 17 Mar 2009 23:49:07 +0200, Aleksej Saushev <as...@in...> wrote: > spvw.d: In function `init_multithread': > spvw.d:629: error: `PTHREAD_MUTEX_RECURSIVE_NP' undeclared (first use in > this function) Looks like pthreads in FreeBSD are like in OSX. Please try the patch that follows - if it's ok, i'll commit it. Vladimir ------------------------------- vtz@vtz:~/clisp/dev/src$ diff -u xthread.d ../../commit/src/xthread.d --- xthread.d 2009-03-17 23:54:26.000000000 +0200 +++ ../../commit/src/xthread.d 2009-02-04 14:21:17.000000000 +0200 @@ -113,7 +113,7 @@ /* cache the global mutex attribute for recursive mutex creation */ extern pthread_mutexattr_t recursive_mutexattr; /* osx follows posix, linux defines _NP attributes */ -#if defined(UNIX_MACOSX) || defined(UNIX_FREEBSD) +#ifdef UNIX_MACOSX #define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE #endif #define xthread_init() |
From: Aleksej S. <as...@in...> - 2009-03-17 23:13:51
|
"Vladimir Tzankov" <vtz...@gm...> writes: > On Tue, 17 Mar 2009 23:49:07 +0200, Aleksej Saushev <as...@in...> wrote: >> spvw.d: In function `init_multithread': >> spvw.d:629: error: `PTHREAD_MUTEX_RECURSIVE_NP' undeclared (first use in >> this function) > > Looks like pthreads in FreeBSD are like in OSX. > Please try the patch that follows - if it's ok, i'll commit it. I've modified your patch: --- src/xthread.d.orig 2009-03-17 23:54:26.000000000 +0200 +++ src/xthread.d 2009-02-04 14:21:17.000000000 +0200 @@ -113,7 +113,7 @@ /* cache the global mutex attribute for recursive mutex creation */ extern pthread_mutexattr_t recursive_mutexattr; /* osx follows posix, linux defines _NP attributes */ -#ifdef UNIX_MACOSX +#if defined(UNIX_MACOSX) || defined(UNIX_FREEBSD) #define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE #endif #define xthread_init() \ The build fails with: ;; Loading file /h/obj/wip/clisp/work/clisp/src/russian.lisp ... ;; Loaded file /h/obj/wip/clisp/work/clisp/src/russian.lisp ;; Loading file /h/obj/wip/clisp/work/clisp/src/deprecated.lisp ... ;; Loaded file /h/obj/wip/clisp/work/clisp/src/deprecated.lisp ;; Loading file /h/obj/wip/clisp/work/clisp/src/config.lisp ... ;; Loaded file /h/obj/wip/clisp/work/clisp/src/config.lisp Bytes permanently allocated: 99,732 Bytes currently in use: 5,350,000 Bytes available until next GC: 1,337,500 Bye. mv lispimag.mem interpreted.mem ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -M interpreted.mem -q -c compiler.lisp -o ./ ;; Compiling file /h/obj/wip/clisp/work/clisp/src/compiler.lisp ...Segmentation fault (core dumped) *** Error code 139 If you want backtrace, I need time. -- BECHA... CKOPO CE3OH... |
From: Vladimir T. <vtz...@gm...> - 2009-03-18 06:12:22
|
On Wed, 18 Mar 2009 01:13:27 +0200, Aleksej Saushev <as...@in...> wrote: > The build fails with: > > ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m > 2MW -M interpreted.mem -q -c compiler.lisp -o ./ > ;; Compiling file /h/obj/wip/clisp/work/clisp/src/compiler.lisp > ...Segmentation fault (core dumped) > *** Error code 139 > > If you want backtrace, I need time. Yes, bit will help. I assume that without threads it builds fine. Right? Can you try without generational GC (CFLAGS=-NO_GENERATIONAL_GC)? Vladimir |
From: Aleksej S. <as...@in...> - 2009-03-18 17:18:54
|
"Vladimir Tzankov" <vtz...@gm...> writes: > On Wed, 18 Mar 2009 01:13:27 +0200, Aleksej Saushev <as...@in...> wrote: >> The build fails with: >> >> ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m >> 2MW -M interpreted.mem -q -c compiler.lisp -o ./ >> ;; Compiling file /h/obj/wip/clisp/work/clisp/src/compiler.lisp >> ...Segmentation fault (core dumped) >> *** Error code 139 >> >> If you want backtrace, I need time. > > Yes, bit will help. > > I assume that without threads it builds fine. Right? > Can you try without generational GC (CFLAGS=-NO_GENERATIONAL_GC)? cc -I/home/asau/pkg/include -I/usr/include -Igllib -DNO_GENERATIONAL_GC -I/home/asau/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -c spvw.c spvw.d: In function `main_actions': spvw.d:3565: warning: variable 'fileptr' might be clobbered by `longjmp' or `vfork' spvw.d:3566: warning: variable 'count' might be clobbered by `longjmp' or `vfork' spvw.d:3546: warning: variable 'fileptr' might be clobbered by `longjmp' or `vfork' spvw.d:3547: warning: variable 'count' might be clobbered by `longjmp' or `vfork' cc -I/home/asau/pkg/include -I/usr/include -Igllib -DNO_GENERATIONAL_GC -I/home/asau/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -c spvwtabf.c cc -I/home/asau/pkg/include -I/usr/include -Igllib -DNO_GENERATIONAL_GC -I/home/asau/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -c spvwtabs.c cc -I/home/asau/pkg/include -I/usr/include -Igllib -DNO_GENERATIONAL_GC -I/home/asau/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -c spvwtabo.c ... ;; Loading file /h/obj/wip/clisp/work/clisp/src/russian.lisp ... ;; Loaded file /h/obj/wip/clisp/work/clisp/src/russian.lisp ;; Loading file /h/obj/wip/clisp/work/clisp/src/deprecated.lisp ... ;; Loaded file /h/obj/wip/clisp/work/clisp/src/deprecated.lisp ;; Loading file /h/obj/wip/clisp/work/clisp/src/config.lisp ... ;; Loaded file /h/obj/wip/clisp/work/clisp/src/config.lisp Bytes permanently allocated: 99,732 Bytes currently in use: 5,348,056 Bytes available until next GC: 2,674,028 Bye. mv lispimag.mem interpreted.mem ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -M interpreted.mem -q -c compiler.lisp -o ./ ;; Compiling file /h/obj/wip/clisp/work/clisp/src/compiler.lisp ...Segmentation fault (core dumped) *** Error code 139 No way. I'll try to get a backtrace. -- BECHA... CKOPO CE3OH... |
From: Aleksej S. <as...@in...> - 2009-03-19 19:02:55
|
Aleksej Saushev <as...@in...> writes: > mv lispimag.mem interpreted.mem > ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -M interpreted.mem -q -c compiler.lisp -o ./ > ;; Compiling file /h/obj/wip/clisp/work/clisp/src/compiler.lisp ...Segmentation fault (core dumped) > *** Error code 139 > > > No way. > > I'll try to get a backtrace. Stack printout doesn't reveal anything, the only thing I could extract is this: (gdb) info threads * 4 LWP 100095 0x283dcb9b in pthread_testcancel () from /lib/libpthread.so.2 3 Thread 0x8254000 (sleeping) 0x283d4dc4 in pthread_mutexattr_init () from /lib/libpthread.so.2 2 Thread 0x8254200 (LWP 100105) 0x283dcb9b in pthread_testcancel () from /lib/libpthread.so.2 1 Thread 0x8254400 (runnable) 0x283ddb91 in __error () from /lib/libpthread.so.2 If you have better ideas what I should look for, tell me. -- BECHA... CKOPO CE3OH... |
From: Vladimir T. <vtz...@gm...> - 2009-03-19 19:48:50
|
On Thu, 19 Mar 2009 21:02:33 +0200, Aleksej Saushev <as...@in...> wrote: > Stack printout doesn't reveal anything, the only thing I could extract > is this: > > (gdb) info threads > * 4 LWP 100095 0x283dcb9b in pthread_testcancel () from > /lib/libpthread.so.2 > 3 Thread 0x8254000 (sleeping) 0x283d4dc4 in pthread_mutexattr_init () > from /lib/libpthread.so.2 > 2 Thread 0x8254200 (LWP 100105) 0x283dcb9b in pthread_testcancel () > from /lib/libpthread.so.2 > 1 Thread 0x8254400 (runnable) 0x283ddb91 in __error () from > /lib/libpthread.so.2 > > If you have better ideas what I should look for, tell me. You may issue "where" in gdb to inspect the call stack of "current" thread (and switch between them via "thread xx"). I am installing now FreeBSD 6 (6.4 stable) in VirtualBox - will try to check it. Vladimir |
From: Vladimir T. <vtz...@gm...> - 2009-03-20 21:45:26
|
On Thu, 19 Mar 2009 21:02:33 +0200, Aleksej Saushev <as...@in...> wrote: > Aleksej Saushev <as...@in...> writes: > >> mv lispimag.mem interpreted.mem >> ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m >> 2MW -M interpreted.mem -q -c compiler.lisp -o ./ >> ;; Compiling file /h/obj/wip/clisp/work/clisp/src/compiler.lisp >> ...Segmentation fault (core dumped) >> *** Error code 139 This particular problem is caused by the default thread implementation on FreeBSD 6 - libpthread. Since I am not familiar with FreeBSD - here is what I learned today - correct me if I am wrong. There are three threads implementations on FreeBSD 6 - libpthread (user space threads - M:1), libthr (kernel threads 1:1) and kse (N:M). libpthread is the default on FreeBSD 6 and causes the above. I am not sure for the exact reason but there are other programs that experience similar problems with it. libpthread looks like deprecated in FreeBSD 7 and the default one is libthr (kernel threads 1:1 - the same as NPTL on linux). With libthr clisp "almost" builds on both FreeBSD 6 and 7. "Almost" since it builds the boot image and hangs on building the linking sets. Also it hangs on check-tests. Not sure what causes the hanging (it happens inside kernel mutex lock) - now I am looking on it - there are reports for similar problem. In order to build with libthr on FreeBSD 6 (on 7 it is default) there are two options: 1. remove from CFLAGS -pthread and add -lthr linker flag (seems the better way). 2. use /etc/libmap.conf to map libpthread.so to libthr.so (there are bug reports stating that symbols from both libs get mixed and bad things happen). Have not tried kse, since 1:1 threading is what we have on linux and win32. Vladimir |
From: Vladimir T. <vtz...@gm...> - 2009-03-23 08:38:29
|
> On Thu, 19 Mar 2009 21:02:33 +0200, Aleksej Saushev <as...@in...> > wrote: > >> Aleksej Saushev <as...@in...> writes: >> >>> mv lispimag.mem interpreted.mem >>> ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m >>> 2MW -M interpreted.mem -q -c compiler.lisp -o ./ >>> ;; Compiling file /h/obj/wip/clisp/work/clisp/src/compiler.lisp >>> ...Segmentation fault (core dumped) >>> *** Error code 139 Should be fixed in the CVS HEAD. I tested it on FreeBSD 7, however the problem was quite generic one - uninitialized mutexes for the standard packages. Vladimir |
From: Sam S. <sd...@gn...> - 2009-03-17 22:12:15
|
Hi, Aleksej Saushev wrote: > > I have problem on FreeBSD 6.3-STABLE i386: > > cc -I/home/asau/pkg/include -I/usr/include -Igllib -O2 -I/home/asau/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -c spvw.c > spvw.d: In function `init_multithread': > spvw.d:629: error: `PTHREAD_MUTEX_RECURSIVE_NP' undeclared (first use in this function) > spvw.d:629: error: (Each undeclared identifier is reported only once > spvw.d:629: error: for each function it appears in.) > *** Error code 1 does this help? -- xthread.d.~1.21.~ 2009-02-05 11:28:48.000000000 -0500 +++ xthread.d 2009-03-17 18:11:32.000273000 -0400 @@ -113,7 +113,7 @@ /* cache the global mutex attribute for recursive mutex creation */ extern pthread_mutexattr_t recursive_mutexattr; /* osx follows posix, linux defines _NP attributes */ -#ifdef UNIX_MACOSX +#ifndef PTHREAD_MUTEX_RECURSIVE_NP #define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE #endif #define xthread_init() \ |
From: Vladimir T. <vtz...@gm...> - 2009-03-17 22:24:56
|
On Wed, 18 Mar 2009 00:12:12 +0200, Sam Steingold <sd...@gn...> wrote: > does this help? > > -- xthread.d.~1.21.~ 2009-02-05 11:28:48.000000000 -0500 > +++ xthread.d 2009-03-17 18:11:32.000273000 -0400 > @@ -113,7 +113,7 @@ > /* cache the global mutex attribute for recursive mutex creation */ > extern pthread_mutexattr_t recursive_mutexattr; > /* osx follows posix, linux defines _NP attributes */ > -#ifdef UNIX_MACOSX > +#ifndef PTHREAD_MUTEX_RECURSIVE_NP > #define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE > #endif > #define > xthread_init() \ It will break the build on linux - PTHREAD_MUTEX_RECURSIVE_NP is enum on linux and absent on OSX. |
From: Aleksej S. <as...@in...> - 2009-03-17 23:22:50
|
Sam Steingold <sd...@gn...> writes: > Aleksej Saushev wrote: >> >> I have problem on FreeBSD 6.3-STABLE i386: >> >> cc -I/home/asau/pkg/include -I/usr/include -Igllib -O2 -I/home/asau/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -c spvw.c >> spvw.d: In function `init_multithread': >> spvw.d:629: error: `PTHREAD_MUTEX_RECURSIVE_NP' undeclared (first use in this function) >> spvw.d:629: error: (Each undeclared identifier is reported only once >> spvw.d:629: error: for each function it appears in.) >> *** Error code 1 > > does this help? > > -- xthread.d.~1.21.~ 2009-02-05 11:28:48.000000000 -0500 > +++ xthread.d 2009-03-17 18:11:32.000273000 -0400 > @@ -113,7 +113,7 @@ > /* cache the global mutex attribute for recursive mutex creation */ > extern pthread_mutexattr_t recursive_mutexattr; > /* osx follows posix, linux defines _NP attributes */ > -#ifdef UNIX_MACOSX > +#ifndef PTHREAD_MUTEX_RECURSIVE_NP > #define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE > #endif > #define xthread_init() \ No, result is the same as above (core dump). -- BECHA... CKOPO CE3OH... |