| 
      
      
      From: <don...@is...> - 2011-02-02 22:49:43
       | 
| 
(all bug reports related to MT go to -devel, right?)
This was an unpleasant surprise.  I've just made a small improvement
to my debug server.  The new code is below.  The difference is that
in addition to debugging an existing thread you can create a new one.
I find that in the new thread, if I enter (mt::list-threads) I get
a segfault!  The old threads don't do that.
I'm afraid I'm building up a backlog of bugs to be fixed when cvs
returns.  I think the current list includes, in addition to this one,
 performance change over last 10 years
 bug in loop? 
====
(defvar *debug-server-port* 1234)
(defun show-socket-addrs(socket) 
  (multiple-value-bind 
      (local-host local-port) 
      (socket:socket-stream-local socket) 
    (multiple-value-bind 
        (remote-host remote-port) 
        (socket:socket-stream-peer socket) 
      (format t "~&Connection: ~S:~D -- ~S:~D~%" 
              remote-host remote-port local-host local-port)))) 
(defun debug-server() 
  (let ((server (socket:socket-server *debug-server-port* 
                                      :interface "localhost"))) 
       (unwind-protect 
           (loop 
            (let ((socket (socket:socket-accept server :buffered nil))) 
              (show-socket-addrs socket) 
              (let ((tlist (loop for x in (mt:list-threads) as i from 1 
                             when (mt:thread-active-p x) collect (cons i x))) 
                    ans) 
                (print tlist socket) 
                (format socket 
                        "~&enter the number of a thread to interrupt debug ~ 
                         or something else that can be read in order to ~ 
                         create a new one: ") 
                (setf ans (or (cdr (assoc (read socket) tlist)) 
                              (mt:make-thread #'read :name "listener"))) 
                (mt:thread-interrupt 
                 ans 
                 :function 
                 (lambda nil 
                   (let ((*standard-input* socket) 
                         (*standard-output* socket) 
                         (*debug-io* socket) 
                         (*error-output* socket) 
                         (*trace-output* socket) 
                         (*query-io* socket)) 
                     (unwind-protect 
                         (break "debug") 
                       (close socket))))))))) 
         (socket:socket-server-close server))) 
 
(mt:make-thread #'debug-server :name "debug-server")
====
instructions:
run MT version of current cvs clisp
execute all above
telnet to localhost port 1234
This gives you a choice of breaking main thread or debug server or
creating a new listener, e.g., by typing 1, 2, or t
 | 
| 
      
      
      From: Vladimir T. <vtz...@gm...> - 2011-02-03 07:54:44
       | 
| On 2/3/11, Don Cohen <don...@is...> wrote: > > (all bug reports related to MT go to -devel, right?) yes > This was an unpleasant surprise. I've just made a small improvement > to my debug server. The new code is below. The difference is that > in addition to debugging an existing thread you can create a new one. > I find that in the new thread, if I enter (mt::list-threads) I get > a segfault! The old threads don't do that. I cannot reproduce the problem (tested on 32bit osx & linux and 64 bit osx). Can you run the whole thing under gdb and paste here the stack trace of segfaulted thread? Vladimir | 
| 
      
      
      From: <don...@is...> - 2011-02-03 08:20:03
       | 
| Vladimir Tzankov writes:
 > On 2/3/11, Don Cohen <don...@is...> wrote:
 > >
 > > (all bug reports related to MT go to -devel, right?)
 > yes
 > 
 > > This was an unpleasant surprise.  I've just made a small improvement
 > > to my debug server.  The new code is below.  The difference is that
 > > in addition to debugging an existing thread you can create a new one.
 > > I find that in the new thread, if I enter (mt::list-threads) I get
 > > a segfault!  The old threads don't do that.
 > 
 > I cannot reproduce the problem (tested on 32bit osx & linux and 64 bit osx).
 > Can you run the whole thing under gdb and paste here the stack trace
 > of segfaulted thread?
 > 
 > Vladimir
I hope this is what you want.  I don't have a very strong idea of what
I'm doing here.  I notice that my first copy/paste added some spaces
to the ends of lines, which ended up causing a format error.
The original error was on old linux 32 bit, this is new linux 64 bit.
Anyway, if this isn't what you want, tell me how to fix it.
(gdb) run
Starting program: /tmp/ap5-2.49+MT 
[Thread debugging using libthread_db enabled]
STACK size: 98222 [0x7ffff2140e00 0x7ffff2081090]
[New Thread 0x7ffff2080700 (LWP 2364)]
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8
Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.cons.org/>
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010
Type :h and hit Enter for context help.
[1]> (defvar *debug-server-port* 1234)
(defun show-socket-addrs(socket)
  (multiple-value-bind
      (local-host local-port)
      (socket:socket-stream-local socket)
    (multiple-value-bind
        (remote-host remote-port)
        (socket:socket-stream-peer socket)
      (format t "~&Connection: ~S:~D -- ~S:~D~%"
              remote-host remote-port local-host local-port))))
*DEBUG-SERVER-PORT*
[2]> SHOW-SOCKET-ADDRS
[3]> (defun debug-server()
  (let ((server (socket:socket-server *debug-server-port*
                                      :interface "localhost")))
       (unwind-protect
           (loop
            (let ((socket (socket:socket-accept server :buffered nil)))
              (show-socket-addrs socket)
              (let ((tlist (loop for x in (mt:list-threads) as i from 1
                             when (mt:thread-active-p x) collect (cons i x)))
                    ans)
                (print tlist socket)
                (format socket
                        "~&enter the number of a thread to interrupt debug ~
                         or something else that can be read in order to ~
                         create a new one: ")
                (setf ans (or (cdr (assoc (read socket) tlist))
                              (mt:make-thread #'read :name "listener")))
                (mt:thread-interrupt
                 ans
                 :function
                 (lambda nil
                   (let ((*standard-input* socket)
                         (*standard-output* socket)
                         (*debug-io* socket)
                         (*error-output* socket)
                         (*trace-output* socket)
                         (*query-io* socket))
                     (unwind-protect
                         (break "debug")
                       (close socket)))))))))
         (socket:socket-server-close server)))
DEBUG-SERVER
[4]> (mt:make-thread #'debug-server :name "debug-server")
[New Thread 0x7ffff0fb8700 (LWP 2371)]
#<THREAD "debug-server">
[5]> 
Connection: "127.0.0.1 (localhost.localdomain)":37791 -- "127.0.0.1 (number11.don-eve.dyndns.org)":1234
[New Thread 0x7ffff0bea700 (LWP 2373)]
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7ffff0bea700 (LWP 2373)]
0x000000309e20e1ac in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) help
List of classes of commands:
aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
running -- Running the program
stack -- Examining the stack
status -- Status inquiries
support -- Support facilities
tracepoints -- Tracing of program execution without stopping the program
user-defined -- User-defined commands
Type "help" followed by a class name for a list of commands in that class.
Type "help all" for the list of all commands.
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) help running
Running the program.
List of commands:
advance -- Continue the program up to the given location (same form as args for break command)
attach -- Attach to a process or file outside of GDB
continue -- Continue program being debugged
detach -- Detach a process or file previously attached
detach checkpoint -- Detach from a checkpoint (experimental)
detach inferior -- Detach from inferior ID
disconnect -- Disconnect from a target
finish -- Execute until selected stack frame returns
handle -- Specify how to handle a signal
inferior -- Use this command to switch between inferiors
interrupt -- Interrupt the execution of the debugged program
jump -- Continue program being debugged at specified line or address
kill -- Kill execution of program being debugged
kill inferior -- Kill inferior ID
next -- Step program
nexti -- Step one instruction
reverse-continue -- Continue program being debugged but run it in reverse
reverse-finish -- Execute backward until just before selected stack frame is called
reverse-next -- Step program backward
reverse-nexti -- Step backward one instruction
reverse-step -- Step program backward until it reaches the beginning of another source line
reverse-stepi -- Step backward exactly one instruction
run -- Start debugged program
signal -- Continue program giving it signal specified by the argument
start -- Run the debugged program until the beginning of the main procedure
step -- Step program until it reaches a different source line
stepi -- Step one instruction exactly
target -- Connect to a target machine or process
target child -- Unix child process (started by the "run" command)
target core -- Use a core file as a target
target exec -- Use an executable file as a target
target extended-remote -- Use a remote computer via a serial line
target multi-thread -- Threads and pthreads support
target record -- Log program while executing and replay execution from log
target record-core -- Log program while executing and replay execution from log
target remote -- Use a remote computer via a serial line
target tfile -- Use a trace file as a target
task -- Use this command to switch between Ada tasks
thread -- Use this command to switch between threads
thread apply -- Apply a command to a list of threads
thread apply all -- Apply a command to all threads
until -- Execute until the program reaches a source line greater than the current
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x000000000062f3ac in plist_find (plist_=0x9c1340, key=...)
    at ../src/symbol.d:30
30	    if (eq(Car(plistr),key)) /* found */
(gdb) help stack
Examining the stack.
The stack is made up of stack frames.  Gdb assigns numbers to stack frames
counting from zero for the innermost (currently executing) frame.
At any time gdb identifies one frame as the "selected" frame.
Variable lookups are done with respect to the selected frame.
When the program being debugged stops, gdb selects the innermost frame.
The commands below can be used to select other frames by number or address.
List of commands:
backtrace -- Print backtrace of all stack frames
bt -- Print backtrace of all stack frames
down -- Select and print stack frame called by this one
frame -- Select and print a stack frame
return -- Make selected stack frame return to its caller
select-frame -- Select a stack frame without printing anything
up -- Select and print stack frame that called this one
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) bt
#0  0x000000000062f3ac in plist_find (plist_=0x9c1340, key=...)
    at ../src/symbol.d:30
#1  0x000000000062f444 in get (symbol=..., key=...) at ../src/symbol.d:45
#2  0x000000000062a5c5 in expand_deftype (type_spec=..., once_p=false)
    at ../src/predtype.d:2166
#3  0x000000000062a953 in C_expand_deftype () at ../src/predtype.d:2195
#4  0x00000000004a2552 in funcall_subr (fun=..., args_on_stack=1)
    at ../src/eval.d:5227
#5  0x00000000004a1112 in funcall (fun=..., args_on_stack=1)
    at ../src/eval.d:4867
#6  0x00000000004a8bff in interpret_bytecode_ (closure=..., 
    codeptr=0x333e9a2e0, 
    byteptr=0x333e9a2fa "\373\024\217\030\200\350\257\333\070\001\201\236")
    at ../src/eval.d:6793
#7  0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=3)
    at ../src/eval.d:5630
#8  0x00000000004a113f in funcall (fun=..., args_on_stack=3)
    at ../src/eval.d:4869
#9  0x00000000004a89d6 in interpret_bytecode_ (closure=..., 
    codeptr=0x333e9fc10, 
    byteptr=0x333e9fc37 "d@\002\021H\031\004\031\004@\034\275\064\003")
    at ../src/eval.d:6787
#10 0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=2)
    at ../src/eval.d:5630
#11 0x00000000004a113f in funcall (fun=..., args_on_stack=2)
    at ../src/eval.d:4869
#12 0x00000000006154ff in C_clcs_signal (argcount=0, 
    rest_args_pointer=0x7ffff0beb5f0) at ../src/error.d:805
#13 0x00000000004a242b in funcall_subr (fun=..., args_on_stack=0)
    at ../src/eval.d:5222
#14 0x00000000004a1084 in funcall (fun=..., args_on_stack=1)
    at ../src/eval.d:4860
#15 0x00000000006115dd in signal_and_debug (condition=...)
    at ../src/error.d:206
#16 0x000000000061296d in end_error (stackptr=0x7ffff0beb5b0, 
    start_driver_p=true) at ../src/error.d:346
#17 0x0000000000612a24 in prepare_error (errortype=package_error, 
    errorstring=0x7133a0 "~S from ~S: there is no package with name ~S", 
    start_driver_p=true) at ../src/error.d:365
#18 0x0000000000612a52 in error (errortype=package_error, 
    errorstring=0x7133a0 "~S from ~S: there is no package with name ~S")
    at ../src/error.d:378
#19 0x000000000054a2b0 in read_internal (stream_=0x7ffff0beb558)
    at ../src/io.d:2096
#20 0x000000000054a600 in read_recursive (stream_=0x7ffff0beb558)
    at ../src/io.d:2141
#21 0x000000000054ab84 in read_recursive_no_dot (stream_=0x7ffff0beb558)
    at ../src/io.d:2176
#22 0x000000000054caeb in read_delimited_list_recursive (
    stream_=0x7ffff0beb558, endch=..., ifdotted=...) at ../src/io.d:2367
#23 0x000000000054c535 in read_delimited_list (stream_=0x7ffff0beb558, 
    endch=..., ifdotted=...) at ../src/io.d:2332
#24 0x000000000054d605 in C_lpar_reader () at ../src/io.d:2497
#25 0x00000000004a2552 in funcall_subr (fun=..., args_on_stack=2)
    at ../src/eval.d:5227
#26 0x00000000004a1084 in funcall (fun=..., args_on_stack=2)
    at ../src/eval.d:4860
#27 0x0000000000548b97 in read_macro (ch=..., stream_=0x7ffff0beb470)
    at ../src/io.d:1793
#28 0x0000000000549580 in read_internal (stream_=0x7ffff0beb470)
    at ../src/io.d:1894
#29 0x000000000054b9d1 in read_top (stream_=0x7ffff0beb470, whitespace_p=...)
    at ../src/io.d:2263
#30 0x000000000054c027 in stream_read (stream_=0x7ffff0beb470, 
    recursive_p=..., whitespace_p=...) at ../src/io.d:2292
#31 0x000000000060875b in read_form () at ../src/debug.d:292
#32 0x00000000006092c9 in C_read_eval_print () at ../src/debug.d:400
#33 0x00000000004a2552 in funcall_subr (fun=..., args_on_stack=2)
    at ../src/eval.d:5227
#34 0x00000000004a1112 in funcall (fun=..., args_on_stack=2)
    at ../src/eval.d:4867
#35 0x00000000004a8e28 in interpret_bytecode_ (closure=..., 
    codeptr=0x334007ee0, 
    byteptr=0x334007efe "\037\n\334\a\002\003\034\002\311R\310R\031\001")
    at ../src/eval.d:6799
#36 0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=0)
    at ../src/eval.d:5630
#37 0x00000000004a10b1 in funcall (fun=..., args_on_stack=0)
    at ../src/eval.d:4862
#38 0x000000000060cdf3 in C_same_env_as () at ../src/debug.d:1013
#39 0x00000000004a2552 in funcall_subr (fun=..., args_on_stack=2)
    at ../src/eval.d:5227
#40 0x00000000004a1112 in funcall (fun=..., args_on_stack=2)
    at ../src/eval.d:4867
#41 0x00000000004a8e28 in interpret_bytecode_ (closure=..., 
    codeptr=0x334007c70, byteptr=0x334007cad "\021M\026\001Q&\020,\006\004")
    at ../src/eval.d:6799
#42 0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=0)
    at ../src/eval.d:5630
#43 0x00000000004a10b1 in funcall (fun=..., args_on_stack=0)
    at ../src/eval.d:4862
#44 0x00000000004c368f in C_driver () at ../src/control.d:1999
#45 0x00000000004a9090 in interpret_bytecode_ (closure=..., 
    codeptr=0x334007760, byteptr=0x3340079c7 "") at ../src/eval.d:6805
#46 0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=3)
    at ../src/eval.d:5630
#47 0x00000000004a10b1 in funcall (fun=..., args_on_stack=3)
    at ../src/eval.d:4862
#48 0x0000000000615298 in C_invoke_debugger () at ../src/error.d:743
#49 0x00000000004a9090 in interpret_bytecode_ (closure=..., 
    codeptr=0x333ff3070, byteptr=0x333ff30e6 "\006\004") at ../src/eval.d:6805
#50 0x000000000049b4fb in eval_closure (closure=...) at ../src/eval.d:3917
#51 0x0000000000494abd in eval1 (form=...) at ../src/eval.d:3091
#52 0x000000000049420d in eval (form=...) at ../src/eval.d:2966
#53 0x00000000004c2d83 in C_unwind_protect () at ../src/control.d:1943
#54 0x00000000004958c5 in eval_fsubr (fun=..., args=...) at ../src/eval.d:3263
#55 0x0000000000494b38 in eval1 (form=...) at ../src/eval.d:3101
#56 0x000000000049420d in eval (form=...) at ../src/eval.d:2966
#57 0x00000000004ba382 in C_let () at ../src/control.d:692
#58 0x00000000004958c5 in eval_fsubr (fun=..., args=...) at ../src/eval.d:3263
#59 0x0000000000494b38 in eval1 (form=...) at ../src/eval.d:3101
#60 0x000000000049420d in eval (form=...) at ../src/eval.d:2966
#61 0x00000000004930b8 in funcall_iclosure (closure=..., 
    args_pointer=0x7ffff0beb058, argcount=0) at ../src/eval.d:2744
#62 0x00000000004a3ffd in funcall_closure (closure=..., args_on_stack=0)
    at ../src/eval.d:5644
#63 0x00000000004a10b1 in funcall (fun=..., args_on_stack=0)
    at ../src/eval.d:4862
#64 0x0000000000484b32 in handle_pending_interrupts () at ../src/spvw.d:4547
#65 0x000000000046b9f9 in allocate_iarray (flags=55 '7', rank=1, type=30)
    at ../src/spvw_typealloc.d:322
#66 0x00000000005449eb in init_reader_low (thr=0x7fffe4001fd0)
    at ../src/io.d:519
#67 0x00000000006ad30e in thread_stub (arg=0x7fffe4001fd0)
    at ../src/zthread.d:260
#68 0x000000309e206d5b in start_thread () from /lib64/libpthread.so.0
#69 0x000000309dae4a7d in clone () from /lib64/libc.so.6
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x000000000062f3ac in plist_find (plist_=0x9c1340, key=...)
    at ../src/symbol.d:30
30	    if (eq(Car(plistr),key)) /* found */
(gdb) continue
Continuing.
[Thread 0x7ffff0bea700 (LWP 2373) exited]
[Thread 0x7ffff0fb8700 (LWP 2371) exited]
[Thread 0x7ffff2080700 (LWP 2364) exited]
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) 
 | 
| 
      
      
      From: Vladimir T. <vtz...@gm...> - 2011-02-03 12:03:23
       | 
| On 2/3/11, Don Cohen <don...@is...> wrote: > ..... > #64 0x0000000000484b32 in handle_pending_interrupts () at ../src/spvw.d:4547 > #65 0x000000000046b9f9 in allocate_iarray (flags=55 '7', rank=1, type=30) > at ../src/spvw_typealloc.d:322 > #66 0x00000000005449eb in init_reader_low (thr=0x7fffe4001fd0) > at ../src/io.d:519 > #67 0x00000000006ad30e in thread_stub (arg=0x7fffe4001fd0) > at ../src/zthread.d:260 > #68 0x000000309e206d5b in start_thread () from /lib64/libpthread.so.0 > #69 0x000000309dae4a7d in clone () from /lib64/libc.so.6 Thanks. While I still cannot reproduce it - the above call stack shows the problem. Thread is being interrupted too early - before it's low-level initialization. While fixing this - another problem with deferred interrupts was revealed. I fixed both issues but sf cvs is still down :(. Vladimir |