On Tue, Dec 04, 2018 at 03:41:48AM -0800, Claus Assmann wrote:
> On Tue, Dec 04, 2018, Otto Moerbeek wrote:
>
> > malloc(3) uses mmap without MAP_STACK flag, so you'll end up with memory
> > not marked MAP_STACK in both cases.
>
> Thanks for the information.
>
> > Define MALLOC_STACK and add
On Dec 4, 2018 5:41 AM, Claus Assmann wrote:
>
> On Tue, Dec 04, 2018, Otto Moerbeek wrote:
>
> > malloc(3) uses mmap without MAP_STACK flag, so you'll end up with memory
> > not marked MAP_STACK in both cases.
>
> Thanks for the information.
>
> > Define MALLOC_STACK and add MAP_STACK to the
On Tue, Dec 04, 2018, Otto Moerbeek wrote:
> malloc(3) uses mmap without MAP_STACK flag, so you'll end up with memory
> not marked MAP_STACK in both cases.
Thanks for the information.
> Define MALLOC_STACK and add MAP_STACK to the flags,
You mean "undefine MALLOC_STACK", right? I don't see a
On Tue, Dec 04, 2018 at 02:33:40AM -0800, Claus Assmann wrote:
> On Mon, Dec 03, 2018, Philip Guenther wrote:
>
> [thanks for the analysis/explanation!]
>
> > And now this kbind() call blows up: the address is not on the original
> > thread's stack but in one of those mmap()s...but those
On Mon, Dec 03, 2018, Philip Guenther wrote:
[thanks for the analysis/explanation!]
> And now this kbind() call blows up: the address is not on the original
> thread's stack but in one of those mmap()s...but those mmap()s were not
> marked as stacks by including MAP_STACK. To quote the
On Mon, 3 Dec 2018, Claus Assmann wrote:
> Here's the dissambler output and the ktrace output follows.
> Unfortunately I don't know enough about this to figure out
> what is wrong, hopefully someone else can (or tell me which
> other information is still needed). TIA!
A close read of the ktrace
On Sun, Dec 02, 2018, Philip Guenther wrote:
> Since ld.so is relinked on each boot, just an address doesn't really show
> what died. The disassembly up to that address would help.
> More important is knowing what signal killed the process. ktracing it and
> seeing what the syscalls leading up
On Sun, Dec 02, 2018, Edgar Pettijohn wrote:
> Sorry just saw it came with some examples. Testing with the `lookupdns'
> program
> ended with a Bus error (core dumped). Here is gdb output:
You might want to download MeTA1 and use its statethreads version,
I'm not sure all of my fixes made it
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,
On Sun, Dec 2, 2018 at 7:51 PM Edgar Pettijohn
wrote:
> Sorry just saw it came with some examples. Testing with the `lookupdns'
> program
> ended with a Bus error (core dumped). Here is gdb output:
>
> Core was generated by `lookupdns'.
> Program terminated with signal SIGBUS, Bus error.
> #0
Sorry just saw it came with some examples. Testing with the `lookupdns' program
ended with a Bus error (core dumped). Here is gdb output:
Core was generated by `lookupdns'.
Program terminated with signal SIGBUS, Bus error.
#0 _longjmp () at /usr/src/lib/libc/arch/amd64/gen/_setjmp.S:99
99
I downloaded state threads from sourceforge and had to make the following
change to get it to build. I didn't test further than just compiling though.
Not sure what you would need to change to get your `autotools' makefiles to
work.
--- ./st-1.9/Makefile Thu Oct 1 17:55:03 2009
+++ Makefile
On Sat, Dec 1, 2018 at 6:34 AM Claus Assmann
wrote:
> statethreads (http://state-threads.sourceforge.net/) crashes on
> OpenBSD 6.4/amd64 (release) with an error in ld (see below); it
> works fine on previous OpenBSD versions. Do I have to set some
> "special" cc/ld options to make this work?
statethreads (http://state-threads.sourceforge.net/) crashes on
OpenBSD 6.4/amd64 (release) with an error in ld (see below); it
works fine on previous OpenBSD versions. Do I have to set some
"special" cc/ld options to make this work? Or are patches to
statehreads required (there doesn't seem to
14 matches
Mail list logo
