Thanks for the replies! Here's an update what I tried so far
-- I will follow the suggestions next.

About the
- signal: it's "segmentation violation".
- syscall: it's accept(2): st_accept invokes that function.

----------
I checked setjmp: no change from 6.3 to 6.4 (cvs diff, comparing
files, etc), and also looked at the current version (4.20) of nspr
(statethreads started out from nspr AFAIR): it has the same definitions
wrt stack layout and no "recent" changes.

----------
I found this which might be relevant:
  * RETGUARD is a replacement for the stack-protector which uses a
    per-function random cookie (located in the ELF .openbsd.randomdata
    section) to consistency check the return address on the stack.
but turning it off using -fno-ret-protector did not help.

----------
Next I tried static linking (because the crash happened in the
dynamic linker): that did not help either
$ ldd server
server:
        Start            End              Type  Open Ref GrpRef Name
        00000b09cff7b000 00000b09d01d9000 dlib  1    0   0      
/home/ca/sm-9/obj.OpenBSD/statethreads/examples/server
$ ./server -l. -b localhost:1234 -a -i
[02/Dec/2018:08:51:23] INFO: process 0 (pid 97666): configuration loaded
[02/Dec/2018:08:51:23] INFO: process 0 (pid 97666): starting 8 threads on 
localhost:1234
Segmentation fault (core dumped) 

neec.esmtp.org$ gdb server{,.core}
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.4"...
Core was generated by `server'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000104bd8b1190a in ?? ()
(gdb) where
#0  0x0000104bd8b1190a in ?? ()
#1  0x0000104bd8b118be in ?? ()
#2  0x00007f7ffffbe5f8 in ?? ()
#3  0xda20e8d18db78ebb in ?? ()
#4  0x0000104e53b14d70 in ?? ()
#5  0x0000104bd8b0590b in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) quit

----------
I also tried whether this could be a problem:
  The Retpoline mitigation against Spectre Variant 2 has been enabled
  in clang(1) and in assembly files on amd64 and i386.
but using -mno-retpoline did not help either.

Reply via email to