Re: Help with some pkgsrc stuff

2009-04-30 Thread Hasso Tepper
Matthew Dillon wrote:
 Upload the core file to leaf, I'll take a look at it to
 try to figure out what the illegal instruction is.

Done.


-- 
Hasso Tepper


Re: Help with some pkgsrc stuff

2009-04-30 Thread Matthew Dillon

:
:Matthew Dillon wrote:
: Upload the core file to leaf, I'll take a look at it to
: try to figure out what the illegal instruction is.
:
:Done.
:
:-- 
:Hasso Tepper

Need the binary too, Hasso :-)

-Matt
Matthew Dillon 
dil...@backplane.com


Re: Help with some pkgsrc stuff

2009-04-30 Thread Hasso Tepper
Matthew Dillon wrote:
 Need the binary too, Hasso :-)

Oops! Uploaded.


-- 
Hasso Tepper


Help with some pkgsrc stuff

2009-04-29 Thread Hasso Tepper
* Mono applications build mostly now after some bugfixes for both mono and 
  DragonFly itself. Applications even run, but die after some seconds of 
  work with following backtrace:

  Core was generated by `mono'.
  Program terminated with signal 4, Illegal instruction.
  #0  0x28265a8c in symlook_list (name=0x804f74b waitpid,
  hash=226539140, objlist=0x28286408, defobj_out=0xbf9fe1d0,
  in_plt=1 '\001', dlp=0xbf9fe1d4)
  at /home/hasso/dragonfly-src/libexec/rtld-elf/rtld.c:2412
  2412{
  (gdb) bt
  #0  0x28265a8c in symlook_list (name=0x804f74b waitpid,
  hash=226539140, objlist=0x28286408, defobj_out=0xbf9fe1d0,
  in_plt=1 '\001', dlp=0xbf9fe1d4)
  at /home/hasso/dragonfly-src/libexec/rtld-elf/rtld.c:2412
  #1  0x282660cc in symlook_default (name=0x804f74b waitpid,
  hash=226539140, refobj=0x28295000, defobj_out=0xbf9fe21c,
  in_plt=1 '\001')
  at /home/hasso/dragonfly-src/libexec/rtld-elf/rtld.c:2356
  #2  0x28266fc0 in find_symdef (symnum=51, refobj=0x28295000,
  defobj_out=0xbf9fe26c, in_plt=1 '\001', cache=0x0)
  at /home/hasso/dragonfly-src/libexec/rtld-elf/rtld.c:1044
  #3  0x28267395 in _rtld_bind (obj=0x28295000, reloff=96,
  stack=0xbf9fe2a8)
  at /home/hasso/dragonfly-src/libexec/rtld-elf/rtld.c:565
  #4  0x282652d6 in _rtld_bind_start ()
  at /home/hasso/dragonfly-src/libexec/rtld-elf/i386/rtld_start.S:83
  #5  0x28295000 in ?? ()
  #6  0x081850d3 in ?? ()
  #7  0x08193256 in ?? ()
  #8  0x08180e8d in ?? ()
  #9  0x283849c3 in thread_start (arg=0x284a0150)
  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_create.c:241
  #10 0x in ?? ()

* After applying the attached patch it's possible to compile www/firefox3
  with jemalloc support (would be a good test to compare it with our
  malloc). The problem is that it goes into infinite loop, seems:

  Core was generated by `firefox-bin'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x2809af80 in malloc_init_hard () at jemalloc.c:5194

  5194{
  (gdb) bt
  #0  0x2809af80 in malloc_init_hard () at jemalloc.c:5194
  #1  0x2809c6c1 in malloc (size=224) at jemalloc.c:5183
  #2  0x2809379e in _thr_alloc (curthread=0x0)
  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_list.c:171
  #3  0x2809201c in _libpthread_init (curthread=0x0)
  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_init.c:215
  #4  0x2809167a in __pthread_mutex_lock (m=0x2809ef74)
  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_private.h:791
  #5  0x2809af9e in malloc_init_hard () at jemalloc.c:1254
  #6  0x2809c6c1 in malloc (size=224) at jemalloc.c:5183
  #7  0x2809379e in _thr_alloc (curthread=0x0)
  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_list.c:171
  #8  0x2809201c in _libpthread_init (curthread=0x0)
  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_init.c:215
  #9  0x2809167a in __pthread_mutex_lock (m=0x2809ef74)
  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_private.h:791
  #10 0x2809af9e in malloc_init_hard () at jemalloc.c:1254
  #11 0x2809c6c1 in malloc (size=224) at jemalloc.c:5183
  #12 0x2809379e in _thr_alloc (curthread=0x0)
  etc etc

Any help to track these problems down is welcome.


-- 
Hasso Tepper
Index: distinfo
===
RCS file: /NetBSD/pkgsrc/www/firefox3/distinfo,v
retrieving revision 1.24
diff -u -p distinfo
--- distinfo	28 Apr 2009 09:14:25 -	1.24
+++ distinfo	29 Apr 2009 07:15:38 -
@@ -4,10 +4,11 @@ SHA1 (firefox-3.0.10-source.tar.bz2) = 67f74cac153d37a
 RMD160 (firefox-3.0.10-source.tar.bz2) = 301ecfe77eef5d0b698b1f1d340b952b1a59ab39
 Size (firefox-3.0.10-source.tar.bz2) = 37081374 bytes
 SHA1 (patch-aa) = f995b5e53fa11ecb659ab2dd10551db1c71cc5f3
-SHA1 (patch-ab) = 4a1704e96b74c76adca615fdf2c9069ca17e9d70
+SHA1 (patch-ab) = e64e0a557301fc0412ea5e3d59fbccf6335e00cf
 SHA1 (patch-ac) = af80f061bdd918a61197c9c499e7d1f5b7d10ebd
 SHA1 (patch-ad) = 20f2184a7e5e98b065e884c67e4c17fc52019a79
 SHA1 (patch-ae) = fea251aabc772c3d4ad3044c8295af45cc9cab2d
+SHA1 (patch-af) = 63c226a1ac9db1595a610693fd1fa35f91caf795
 SHA1 (patch-ap) = 552694ac2d6ca713aec98ec394f1215c048c2392
 SHA1 (patch-ax) = cbfe7a6392d5d2fefff123679ba1c056b1cc0aa9
 SHA1 (patch-ba) = 3bd713cf2edcc61f489cea8269ca60e27c26f1d9
Index: patches/patch-ab
===
RCS file: /NetBSD/pkgsrc/www/firefox3/patches/patch-ab,v
retrieving revision 1.3
diff -u -p patches/patch-ab
--- patches/patch-ab	20 Apr 2009 12:13:03 -	1.3
+++ patches/patch-ab	29 Apr 2009 07:15:38 -
@@ -1,7 +1,7 @@
 $NetBSD: patch-ab,v 1.3 2009/04/20 12:13:03 hasso Exp $
 
 --- configure.in.orig	2008-11-21 21:37:59 +0200
-+++ configure.in	2009-04-20 13:37:54 +0300
 configure.in	2009-04-22 05:48:49 +0300
 @@ -1700,7 +1700,7 @@ case $target in
  LDFLAGS=$_SAVE_LDFLAGS
  ;;
@@ -21,7 +21,7 @@ $NetBSD: patch-ab,v 1.3 

Re: Help with some pkgsrc stuff

2009-04-29 Thread Matthew Dillon
:* Mono applications build mostly now after some bugfixes for both mono and 
:  DragonFly itself. Applications even run, but die after some seconds of 
:  work with following backtrace:
:
:  Core was generated by `mono'.
:  Program terminated with signal 4, Illegal instruction.
:  #0  0x28265a8c in symlook_list (name=0x804f74b waitpid,
:  hash=226539140, objlist=0x28286408, defobj_out=0xbf9fe1d0,
:  in_plt=1 '\001', dlp=0xbf9fe1d4)
:  at /home/hasso/dragonfly-src/libexec/rtld-elf/rtld.c:2412

Upload the core file to leaf, I'll take a look at it to
try to figure out what the illegal instruction is.

:* After applying the attached patch it's possible to compile www/firefox3
:  with jemalloc support (would be a good test to compare it with our
:  malloc). The problem is that it goes into infinite loop, seems:
:
:  Core was generated by `firefox-bin'.
:  Program terminated with signal 11, Segmentation fault.
:  #0  0x2809af80 in malloc_init_hard () at jemalloc.c:5194
:
:  5194{
:  (gdb) bt
:  #0  0x2809af80 in malloc_init_hard () at jemalloc.c:5194
:  #1  0x2809c6c1 in malloc (size=224) at jemalloc.c:5183
:  #2  0x2809379e in _thr_alloc (curthread=0x0)
:  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_list.c:171
:  #3  0x2809201c in _libpthread_init (curthread=0x0)
:  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_init.c:215
:  #4  0x2809167a in __pthread_mutex_lock (m=0x2809ef74)
:  at /home/hasso/dragonfly-src/lib/libthread_xu/thread/thr_private.h:791
:  #5  0x2809af9e in malloc_init_hard () at jemalloc.c:1254
:  #6  0x2809c6c1 in malloc (size=224) at jemalloc.c:5183
:  #7  0x2809379e in _thr_alloc (curthread=0x0)
:...
:Any help to track these problems down is welcome.
:
:-- 
:Hasso Tepper

A pthread/malloc init loop.

There is some additional fragility here, since the mutex itself
probably has to be allocated as well.

Our malloc's use the _SPINLOCK API which allows libthread_xu 
to allocate the initial spinlocks needed for bootstrapping malloc
out of a static array.  It looks like jemalloc is trying to use
core POSIX mutexes right off the bat.

Someone else will have to dig into the jemalloc code, though, I just
don't have time.

-Matt