00:09 pyrimidine joined 00:38 agentzh joined 01:10 pyrimidine joined 02:08 agentzh joined 02:48 ilbot3 joined 04:05 ggoebel joined 06:44 domidumont joined
nwc10 Overnight I had this one again: 06:47
===( 0;61 0/1 23/40 0/? 0/1 0/? 0/? 0/? 31/1610 42/42 Unhandled exception in code scheduled on thread 16
Deocder may not be used concurrently
06:48 domidumont joined 09:02 zakharyas joined 09:08 domidumont joined 09:16 brrt joined
nwc10 and again 09:21
brrt good moarning 09:28
dogbert17 o/ brrt 09:34
also got the dreaded deocder error during the night
got the deocder error again but this time I had a breakpoint in gdb 09:59
gist.github.com/dogbert17/4500c121...8cea06f31c 10:03
brrt i don't really have the background knowledge to judge that appropraitely 10:07
jnthn Well, interesting... 10:12
Increases my confidence we can reproduce it with something smaller, though
dogbert17 I can see what two other threads are doing, one is in 'MVM_frame_find_invokee_multi_ok' and the other in 'gc_free' 10:24
jnthn Are there any other in the decoder, though? 10:27
apply all threads bt 10:28
dogbert17 (gdb) bt
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x37ff0b56:
that also happens with 'apply all threads bt' 10:29
jnthn wat
Python?! 10:30
dogbert17 beats me, probably some plugin stuff for gdb
I'll check all threads individually ...
jnthn Hopefully another one will be in the decoder also 10:31
dogbert17 I can see all except three (the show the python error) and the all say roughly this '#0 0x40024cb0 in ?? ()' 10:34
#1 0x400ff3d2 in start_thread (data=0x42ac6828) at src/core/threads.c:80
brrt oh, that's not so surprising, the python exception 10:35
dogbert17 brrt, please elaborate
brrt you probably have the 'helper' module loaded
and it can't access memory it's trying to print
tools/moar-gdb.py
dogbert17 what do you suggest 10:36
brrt that is probably trying to look at invalid memory 10:37
one thing you can try is to remove the moar-gdb.py script from $wherever-it-was-installed
and see if that helps 10:38
dogbert17 do you know if I can query gdb to see what helpers have been loaded? 10:39
brrt no, i don't 10:40
dogbert17 it hasn't loaded tools/moar-gdb.py it seems, maybe it should 10:43
in gdb I wrote 'info auto-load python-scripts'
brrt hmmm
then it's probably some other python thingy
10:56 zakharyas1 joined
dogbert17 dogbert17 rerunning tests again, this time with --no-optimize 11:09
11:09 brrt joined 11:50 brrt joined 12:30 zakharyas joined 13:34 brrt joined
timotimo moar is not the only place where exceptions don't get their backtrace printed sometimes :\ 13:56
14:10 ggoebel joined
dogbert17 the bug(s) have gone into hiding atm ... 14:40
now I got the 'output-ruler' bug again 14:54
IOninja
.oO( One output to rule them all... )
14:55
15:58 pyrimidine joined 16:14 pyrimidine joined 16:27 pyrimidine joined
TimToady wouldn't it be funny if we turned out to be debugging the GIL there... 17:47
17:48 pyrimidine joined 18:28 pyrimidine joined 19:38 Ven joined 19:53 pyrimidine joined 20:48 ggoebel joined 20:51 Util_ joined 21:19 pyrimidine joined 21:32 pyrimidine joined 21:46 pyrimidine joined 22:19 pyrimidine joined
MasterDuke has anybody looked at heaptrack ( www.kdab.com/heaptrack-v1-0-0-release/ )? think it would be useful? 22:23
23:22 pyrimidine joined