Stephen R. van den Berg wrote:
>A run straight from within gdb give this:
Forget that last one, this might be due to me starting the
pike binary wrong.
--
Stephen.
Stephen R. van den Berg wrote:
>A run straight from within gdb give this:
Tried it again, after less than a second runtime:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation
A run straight from within gdb give this:
SEGFAULT:
(gdb) l
177
178 INIT
179 {
180 struct std_cs_stor *s = THIS;
181
182 s->retain = NULL;
183 s->replace = NULL;
184
185 init_string_builder(>strbuild,0);
186 }
(gdb) p s
$15 = (struct
The most likely cause of this issue might be related to
MutexKeys being lost in the heap, which then get released (a while
later) by the garbage collection. I fixed this problem in a newer
commit; if I run with that fix, the problem does not seem to happen
anymore.
Arne Goedeke wrote:
>Could you
Could you reproduce this when compiled with --with-debug. Then the
blocka allocator has additional checks which might be helpful to debug this.
Arne
On 2019-11-01 09:50, Stephen R. van den Berg wrote:
> This is in a heavy multithreaded application:
>
> Thread 1475 "pike" received signal
Stephen R. van den Berg wrote:
>This is in a heavy multithreaded application:
>I can still explore more structures, have the session still open.
It appears to be undeterministic.
I.e. sometimes the problem occurs after a few seconds after application
start, sometimes it takes more than 10
This is in a heavy multithreaded application:
Thread 1475 "pike" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7574c700 (LWP 14689)]
ba_alloc (a=a@entry=0x5575bf20 )
at /var/src/roxen/81pike/src/block_allocator.c:267
267 p->h.used++;
(gdb) l
262
263
