Possible race condition with append() #6

Closed
wants to merge 1 commit into
from

Conversation

3 participants
@ErrorProne

It seems that some kind of race condition can happen. The append of the group isn't propageted to the DOM-tree when "dom.appendTo("#node_" + this.node.label + " .group2");" is called. So I added the group-dom as additional argument to the log-giles render-function.

This is just a quick hack and not fully tested, but it fixed the problem for me.

Finn
It seems that some kind of race condition can happen. The append of t…
…he group isn't propageted to the DOM-tree when "dom.appendTo("#node_" + this.node.label + " .group2");" is called. So I added the group-dom as additional argument to the log-giles render-function.


This is just a quick hack and not fully tested, but it fixed the problem for me.
@bladeninja

This comment has been minimized.

Show comment Hide comment
@bladeninja

bladeninja Jan 24, 2013

I'm not sure if this is the same condition, but I'm getting a race condition on write (which could be append)

Here is the GDB output for log.io-server

root@xaptum3:~# gdb which node 21341
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
This GDB was configured as "x86_64-linux-gnu".
Reading symbols
[Truncated]
...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7f1138313700 (LWP 18920)]
[New Thread 0x7f113cc37700 (LWP 18919)]
[New Thread 0x7f113cc78700 (LWP 18918)]
[New Thread 0x7f113ccb9700 (LWP 18917)]
[New Thread 0x7f1138b14700 (LWP 21342)]
done.

0x00007f113ae7dccd in write () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) info threads
Id Target Id Frame
6 Thread 0x7f1138b14700 (LWP 21342) "SignalSender" sem_wait () at ... x86_64/sem_wait.S:86
5 Thread 0x7f113ccb9700 (LWP 18917) "node" pthread_cond_wait@@GLIBC_2.3.2 ()
at ... /x86_64/pthread_cond_wait.S:162
4 Thread 0x7f113cc78700 (LWP 18918) "node" pthread_cond_wait@@GLIBC_2.3.2 ()
at ... /x86_64/pthread_cond_wait.S:162
3 Thread 0x7f113cc37700 (LWP 18919) "node" pthread_cond_wait@@GLIBC_2.3.2 ()
at ... /x86_64/pthread_cond_wait.S:162
2 Thread 0x7f1138313700 (LWP 18920) "node" pthread_cond_wait@@GLIBC_2.3.2 ()
at ... /x86_64/pthread_cond_wait.S:162
* 1 Thread 0x7f113cdbc740 (LWP 21341) "node" 0x00007f113ae7dccd in write () at ... /syscall-template.S:82
(gdb)

Wondering if your fix could solve the issue, will keep you posted

I'm not sure if this is the same condition, but I'm getting a race condition on write (which could be append)

Here is the GDB output for log.io-server

root@xaptum3:~# gdb which node 21341
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
This GDB was configured as "x86_64-linux-gnu".
Reading symbols
[Truncated]
...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7f1138313700 (LWP 18920)]
[New Thread 0x7f113cc37700 (LWP 18919)]
[New Thread 0x7f113cc78700 (LWP 18918)]
[New Thread 0x7f113ccb9700 (LWP 18917)]
[New Thread 0x7f1138b14700 (LWP 21342)]
done.

0x00007f113ae7dccd in write () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) info threads
Id Target Id Frame
6 Thread 0x7f1138b14700 (LWP 21342) "SignalSender" sem_wait () at ... x86_64/sem_wait.S:86
5 Thread 0x7f113ccb9700 (LWP 18917) "node" pthread_cond_wait@@GLIBC_2.3.2 ()
at ... /x86_64/pthread_cond_wait.S:162
4 Thread 0x7f113cc78700 (LWP 18918) "node" pthread_cond_wait@@GLIBC_2.3.2 ()
at ... /x86_64/pthread_cond_wait.S:162
3 Thread 0x7f113cc37700 (LWP 18919) "node" pthread_cond_wait@@GLIBC_2.3.2 ()
at ... /x86_64/pthread_cond_wait.S:162
2 Thread 0x7f1138313700 (LWP 18920) "node" pthread_cond_wait@@GLIBC_2.3.2 ()
at ... /x86_64/pthread_cond_wait.S:162
* 1 Thread 0x7f113cdbc740 (LWP 21341) "node" 0x00007f113ae7dccd in write () at ... /syscall-template.S:82
(gdb)

Wondering if your fix could solve the issue, will keep you posted

@msmathers

This comment has been minimized.

Show comment Hide comment
@msmathers

msmathers Feb 21, 2013

Contributor

v0.3.0 uses a completely new view rendering mechanism, which should avoid this problem.

Contributor

msmathers commented Feb 21, 2013

v0.3.0 uses a completely new view rendering mechanism, which should avoid this problem.

@msmathers msmathers closed this Feb 21, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment