Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2013-10-01

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:49 lpabon joined #gluster-dev
01:33 mohankumar joined #gluster-dev
01:43 awheeler joined #gluster-dev
01:51 awheeler joined #gluster-dev
02:02 kshlm joined #gluster-dev
02:07 awheeler_ joined #gluster-dev
04:10 Technicool joined #gluster-dev
05:17 Technicool joined #gluster-dev
06:57 Dga joined #gluster-dev
09:01 rgustafs joined #gluster-dev
09:16 Maxence joined #gluster-dev
09:18 Dga joined #gluster-dev
10:38 edward2 joined #gluster-dev
10:47 kkeithley1 joined #gluster-dev
12:48 awheeler joined #gluster-dev
12:49 awheeler joined #gluster-dev
13:48 bala joined #gluster-dev
14:12 badone joined #gluster-dev
14:18 jbautista joined #gluster-dev
14:22 jclift joined #gluster-dev
14:33 Technicool joined #gluster-dev
14:58 lpabon joined #gluster-dev
15:38 jclift left #gluster-dev
16:14 jbautista joined #gluster-dev
16:29 ndk joined #gluster-dev
18:01 mohankumar johnmark: ping
18:01 * mohankumar looking for hagarth aka vijay bellur
18:10 kkeithley_ hagarth|vbellur is on PTO for two weeks.
18:19 lalatenduM joined #gluster-dev
18:25 kkeithley_ did someone prune out a bunch of old branches or something in the git repo?
18:26 johnmark mohankumar: pong
18:26 johnmark kkeithley_: oh forgot about that
18:27 johnmark mohankumar: I'm about to head out for a while. If you need to reach me, best to find me on google talk/hangout - johnmark@johnmark.org
19:23 mjrosenb_ joined #gluster-dev
19:28 avati joined #gluster-dev
19:29 [o__o] joined #gluster-dev
19:29 a2 kkeithley_, i did a 'git gc'
19:30 a2 reduced repo size from 650MB to 32MB
19:58 kkeithley joined #gluster-dev
20:33 foster a2: ping wrt qemu-block
20:33 a2 pong
20:34 foster a2: the crash appears to be a use after free effectively
20:34 a2 oh?
20:34 foster the cs in the frame, which is freed when the stub is unwind
20:34 foster unwound
20:34 a2 do you have a bt?
20:35 foster some other co internal to qemu attempts to walk its wake up list
20:36 a2 hmm
20:36 foster sort of, my tree is hacked up a bit to try and catch it earlier
20:36 foster #2  0x00007ffff3655ae7 in qemu_co_queue_run_restart (co=0x7fffe4e09fb0) at ../../../../contrib/qemu/qemu-coroutine-lock.c:80
20:36 foster #3  0x00007ffff3655775 in coroutine_swap (from=0x7fffe8077a10, to=0x7fffe4e09fb0) at ../../../../contrib/qemu/qemu-coroutine.c:93
20:36 foster #4  0x00007ffff36558b5 in qemu_coroutine_yield () at ../../../../contrib/qemu/qemu-coroutine.c:136
20:36 foster #5  0x00007ffff36559e1 in qemu_co_queue_wait (queue=0x7fffe8004de0) at ../../../../contrib/qemu/qemu-coroutine-lock.c:51
20:36 foster #6  0x00007ffff3655d65 in qemu_co_mutex_lock (mutex=0x7fffe8004dd8) at ../../../../contrib/qemu/qemu-coroutine-lock.c:145
20:36 foster #7  0x00007ffff3673299 in qcow2_co_writev (bs=0x7fffe8000920, sector_num=10488320, remaining_sectors=31, qiov=0x7fffe540cb60)
20:36 foster that's an internal co
20:37 foster the co param in #2 is a "gluster generated" co
20:37 foster and it has been freed
20:37 a2 oh
20:37 foster also - this appears to be a timing issue related to write-behind
20:38 foster but what I think is happening is basically one write request comes in, it creates a co, subsequently another write comes in, it does the same thing but its internal co ends up waiting on a lock queue
20:39 a2 ...
20:39 foster and somehow *waves hands* the first request finishes up before the calls into the wakeup unwind
20:40 foster i.e., first worker terminates, wakes first top level request
20:40 foster first top level request calls into seconds context via the wake up queue
20:40 a2 ok..
20:40 foster and somehow the first wakes up and returns before that one gets back to handle the firsts wake up queue and return the action
20:41 foster (which is now 0 instead of a valid value, I've seen this manifest as that abort as well)
20:41 a2 ok.. let me refresh my mind with the co code.. it's been a while since i looked at it
20:42 kkeithley_ a2: ah, okay. that explains my recent git clone that only took five seconds instead of ten minutes
20:42 foster a2: ok
20:42 a2 kkeithley, yes, git clones have become much faster after the 'git gc'
20:43 foster a2: I think I can "get around it" in this particular case by letting the synctask die naturally and setting cs->action to TERMINATE
20:43 foster but conversely, I think the cases that don't end up in this twisted call chain would end up being leaked
20:43 foster I haven't quite fully worked it out
20:44 a2 foster, oh ok
20:44 foster (i.e., that pending handler for the "to" co would see the terminate action and delete it)
20:45 foster so iow, perhaps that helps reason about the problem, not quite at a fix :/
20:46 kkeithley_ I didn't know about git gc, learned something new today
20:54 badone joined #gluster-dev
23:30 awheeler joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary