|
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 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
|
|||