Re: crashing socket tests
Vladimir Tzankov <[email protected]>
| Newsgroups | gmane.lisp.clisp.devel |
|---|---|
| Message-ID | <CAHWYE6KPS8d1Q9FW0ztczOHwPctuGURjFeqWEFihZEdMgJvhew@mail.gmail.com> |
Hi Bruno,
Here is narrowed down reproducible stacktrace based on hg tip.
The build is '--without-ffcall'. Really important since I was not able to
reproduce it with FFI enabled.
GNU CLISP 2.49.50+ (2017-03-30) (built 3704559062) (memory 3704559864)
Software: GNU C 4.9.2
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type
-Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral
-Wno-shift-negative-value -O -fwrapv -fno-strict-aliasing -DENABLE_UNICODE
-DNO_TERMCAP_NCURSES -DDYNAMIC_MODULES libgnu.a -ldl -lsigsegv
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_PURE
SINGLEMAP_MEMORY
libsigsegv 2.10
Features:
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL
COMMON-LISP LISP=CL INTERPRETER LOGICAL-PATHNAMES SOCKETS GENERIC-STREAMS
GETTEXT UNICODE BASE-CHAR=CHARACTER
WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/vtz/clisp/s/
User language: ENGLISH
Machine: X86_64 (X86_64) debian [127.0.1.1]
And here is the GDB session:
(gdb) base
(gdb) handle SIGSEGV nostop noprint
Signal Stop Print Pass to program Description
SIGSEGV No No Yes Segmentation fault
(gdb) break spvw_sigsegv.d:64
Breakpoint 1 at 0x42d703: file ../src/spvw_sigsegv.d, line 64.
(gdb) r
Starting program: /home/vtz/clisp/s/base/lisp.run -B . -N locale -E 1:1 -q
-norc -M base/lispinit.mem
[1]> (describe nil)
NIL is the empty list, the symbol NIL, lies in #<PACKAGE COMMON-LISP>, is
accessible in 8 packages CLOS, COMMON-LISP, COMMON-LISP-USER, EXPORTING,
EXT, POSIX, REGEXP, SYSTEM, a
constant, value: NIL, names a type, has 2 properties SYSTEM::INSTRUCTION,
SYSTEM::TYPE-SYMBOL
;; connecting to "
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Data/Map_Sym.txt"...connected...HTTP/1.1
404 Not Found
;; "Date: Tue, 23 May 2017 22:23:10 GMT"
;; "Server: Apache/2.4.7 (Ubuntu)"
;; "Content-Length: 253"
;; "Connection: close"
;; "Content-Type: text/html; charset=iso-8859-1"
;; ""
;; "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">"
;; "<html><head>"
;; "<title>404 Not Found</title>"
;; "</head><body>"
;; "<h1>Not Found</h1>"
;; "<p>The requested URL
/projects/iiip/doc/CommonLISP/HyperSpec/Data/Map_Sym.txt was not found on
this server.</p>"
;; "</body></html>"
;; connecting to "
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Data/Symbol-Table.text"...connected...HTTP/1.1
200 OK...45,322 bytes
;; SYSTEM::GET-CLHS-MAP(#<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER
www.ai.mit.edu:80>)...978/978 symbols
.
ANSI-CL Documentation is at
"
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/any_nil.html
"
;; connecting to "http://clisp.org/impnotes/id-href.map"...connected...HTTP/1.1
200 OK...74,909 bytes
;; SYSTEM::GET-STRING-MAP(#<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER
clisp.org:80>)...
*** - handle_fault error2 ! address = 0xc000001a3b8 not in
[0xc0000000000,0xc0000018ac8) !
Breakpoint 1, sigsegv_handler_failed (address=address@entry=0xc000001a3b8)
at ../src/spvw_sigsegv.d:64
64 fputc('\n',stderr);
(gdb) where 10
#0 sigsegv_handler_failed (address=address@entry=0xc000001a3b8) at
../src/spvw_sigsegv.d:64
#1 0x000000000042da0d in sigsegv_handler (fault_address=0xc000001a3b8,
serious=<optimized out>) at ../src/spvw_sigsegv.d:80
#2 0x00007ffff749ceaf in ?? () from
/usr/lib/x86_64-linux-gnu/libsigsegv.so.2
#3 <signal handler called>
#4 0x0000000000471991 in rd_ch_buffered (stream_=0x30000000360) at
../src/stream.d:6654
#5 0x000000000047fd42 in read_line (stream_=0x30000000360,
buffer_=buffer_@entry=0x30000000350) at ../src/stream.d:16328
#6 0x000000000047fd2b in read_line_twoway (buffer_=0x30000000350,
stream=0xb00000019d8) at ../src/stream.d:2168
#7 read_line (stream_=stream_@entry=0x30000000330, buffer_=0x30000000350)
at ../src/stream.d:16322
#8 0x0000000000490661 in C_read_line () at ../src/io.d:4500
#9 0x0000000000448b5a in interpret_bytecode_ (closure=0x90000048560,
codeptr=0x13000003e538,
byteptr=0x13000003e5c2
"j\002j\002\222\001\377\256k\001\344\260-\003\004\026\003\025\031\002\341ݯ\257-\004\b")
at ../src/eval.d:7653
(More stack frames follow...)
(gdb) frame 4
#4 0x0000000000471991 in rd_ch_buffered (stream_=0x30000000360) at
../src/stream.d:6654
6654 Encoding_mbstowcs(encoding)
(gdb) p encoding
$1 = (object) 0xc000001a380
(gdb) p bufferptr
$2 = (uintB *) 0x13000004cb8f <error: Cannot access memory at address
0x13000004cb8f>
There was no GC run since the startup (double checked it) so it should not
be GC safety issue.
On Tue, May 23, 2017 at 11:36 AM, Bruno Haible <[email protected]> wrote:
> Hi Vladimir,
>
> > Besides this I observe weird behaviour with amd64 builds on linux - both
> > single and multithreaded: without libffcall there is consistent segfault
> on
> > sockets tests while with libffcall enabled everything works fine. Will
> > investigate this further but any clue will be helpful.
>
> I also observed segfaults on or soon after socket tests in various
> configurations in February 2017. It seemed to depend on alignment options,
> but tracking down this route it behaved like a Heisenbug.
>
> A build with GC debugging enabled did not help.
>
> I think to resolve this we need one of the following approaches:
> - Comment out some tests (the socket tests especially) and see if the
> testsuite still crashes occasionally.
> - Review the code of socket.d for ANY kind of mistake (usual GC-safety
> mistakes are not likely - see testing I mentioned above).
> - New kinds of debugging tools, in the spirit of GCC's "sanitizers" or
> valgrind.
>
> Bruno
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel