View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002198 | GNUnet | file-sharing service | public | 2012-03-06 14:05 | 2012-06-02 19:15 |
| Reporter | LRN | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.9.2 | ||||
| Target Version | 0.9.3 | Fixed in Version | 0.9.3 | ||
| Summary | 0002198: Crash in fs service during test_fs_download_indexed | ||||
| Description | r20307+3 | ||||
| Additional Information |
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 13424.0x2804]
0x75c7280d in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
(gdb) bt
#0 0x75c7280d in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
#1 0x61c065a4 in GNUNET_abort () at common_logging.c:271
#2 0x61c0f708 in transmit_ready (cls=0x490898, tc=0x28fc90) at connection.c:1453
#3 0x61c37879 in run_ready (rs=0x378fe8, ws=0x37a000) at scheduler.c:682
#4 0x61c37fea in GNUNET_SCHEDULER_run (task=0x61c428fa <service_task>, task_cls=0x28fe28) at scheduler.c:870
#5 0x61c435de in GNUNET_SERVICE_run (argc=3, argv=0x48c700, serviceName=0x417167 "fs", opt=GNUNET_SERVICE_OPTION_NONE, task=0x401e30 <run>, task_cls=0x0) at service.c:1716
#6 0x00402053 in main (argc=3, argv=0x48c700) at gnunet-service-fs.c:650
(gdb) up 2
#2 0x61c0f708 in transmit_ready (cls=0x490898, tc=0x28fc90) at connection.c:1453
1453 GNUNET_assert (NULL != sock->sock);
(gdb) p *sock
$1 = {cfg = 0x0, ap_head = 0x0, ap_tail = 0x0, addr = 0x37b8d0, hostname = 0x0, sock = 0x0, receiver = 0, receiver_cls = 0x490360, write_buffer = 0x4de108 "А\030", write_buffer_size = 32792, write_buffer_off = 32792,
write_buffer_pos = 0, addrlen = 28, read_task = 0, write_task = 0, destroy_task = 0, dns_active = 0x0, nth = {notify_ready = 0, notify_ready_cls = 0x490360, sh = 0x490898, transmit_timeout = {
abs_value = 18446744073709551615}, timeout_task = 0, notify_size = 32792}, receive_timeout = {abs_value = 18446744073709551615}, ccs = COCO_NONE, max = 65535, ignore_shutdown = 0, port = 0, persist = 0}
| ||||
| Tags | No tags attached. | ||||
|
|
When run with full global DEBUG logging it randomly succeeds (instead of always failing). I have two 5MB log files, one for a run without crashes, another - with a crash. What immediately caught my attention are these lines only present in crash-log: util-11280 DEBUG Accepting connection on `0.0.0.0:43471'util-11280 WARNING `accept' failed at connection.c:383 with error: Resource unavailable or operation would block, try again util-11280 WARNING `accept' failed at connection.c:383 with error: Resource unavailable or operation would block, try again util-11280 DEBUG Error receiving: Resource unavailable or operation would block, try again util-11280 DEBUG Timeout in receive_helper, available 0, conn->sock non-NULL, errCode `No error' |
|
|
util-15992 DEBUG Connection to `[::1]:2098' succeeded! (0x611898) util-15992 DEBUG connect_success_continuation runs receive_again (0x611898) util-scheduler-15992 DEBUG Adding task: 35 / 0x611898 ... util-scheduler-15992 DEBUG Running task: 34 / 0x53fe10 util-15992 DEBUG transmit_ready running (0x53fe10). core-api-15992 DEBUG Transmitting control message with 14 bytes of type 64 to core. util-15992 DEBUG calling GNUNET_CONNECTION_receive util-scheduler-15992 DEBUG Adding task: 40 / 0x53fe10 core-api-15992 DEBUG Core connection down, not processing queue util-15992 DEBUG transmit_ready transmitted 14/14 bytes to `[::1]:43470' (0x53fe10) util-scheduler-15992 DEBUG Running task: 36 / 0x611898 ... util-scheduler-15992 DEBUG Running task: 40 / 0x53fe10 util-15992 DEBUG receive_ready read 72/65535 bytes from `[::1]:43470' (0x53fe10)! util-scheduler-15992 DEBUG Adding task: 47 / 0x65c408 ... util-scheduler-15992 DEBUG Running task: 35 / 0x611898 util-scheduler-15992 DEBUG Adding task: 43 / 0x611898 ... util-scheduler-15992 DEBUG Running task: 47 / 0x65c408 util-15992 DEBUG Received message of type 65 and size 72 core-api-15992 DEBUG Request queue empty, not processing queue core-api-15992 DEBUG Connected to core service of peer `H9P7'. util-15992 DEBUG calling GNUNET_CONNECTION_receive util-scheduler-15992 DEBUG Adding task: 48 / 0x53fe10 ... fs-15992 DEBUG Received reply for `LAVVRGS7' of type 1 with UID 1 from datastore. fs-15992 DEBUG Matched result (type 1) for query `LAVVRGS7' with pending request util-15992 DEBUG Scheduling transmit_ready (0x6100c8). util-scheduler-15992 DEBUG Adding task: 259 / 0x6100c8 fs-15992 DEBUG Queued reply to query `LAVVRGS7' for local client fs-15992 DEBUG Finished database lookup for local request `LAVVRGS7' with result 1 util-scheduler-15992 DEBUG Canceling task: 233 / 0x60f638 util-15992 DEBUG GNUNET_SERVER_receive_done causes restart in reading from the socket util-scheduler-15992 DEBUG Adding task: 260 / 0x60f638 ... util-scheduler-15992 DEBUG Running task: 259 / 0x6100c8 util-15992 DEBUG transmit_ready running (0x6100c8). util-15992 DEBUG Scheduling transmit_ready (0x6100c8). util-scheduler-15992 DEBUG Adding task: 386 / 0x6100c8 util-15992 DEBUG `send' failed at connection.c:1497 with error: Connection reset by peer util-15992 DEBUG Closed 0x284, closesocket() returned 0, GLE is 0 ... util-scheduler-15992 DEBUG Running task: 140 / 0x60d9f8 util-15992 DEBUG Accepting connection on `0.0.0.0:43471' util-15992 WARNING `accept' failed at connection.c:383 with error: Resource unavailable or operation would block, try again util-15992 WARNING `accept' failed at connection.c:383 with error: Resource unavailable or operation would block, try again util-scheduler-15992 DEBUG Adding task: 393 / 0x60d9f8 util-scheduler-15992 DEBUG Running task: 43 / 0x611898 util-15992 DEBUG Error receiving: Resource unavailable or operation would block, try again util-15992 DEBUG Timeout in receive_helper, available 0, conn->sock non-NULL, errCode `No error' util-scheduler-15992 DEBUG Adding task: 394 / 0x611898 util-scheduler-15992 DEBUG Adding task: 395 / 0x629a90 ... util-scheduler-15992 DEBUG Running task: 394 / 0x611898 util-15992 DEBUG Shutting down socket (0x611898) util-15992 DEBUG Destroy actually runs (0x611898)! util-15992 DEBUG Closed 0x274, closesocket() returned 0, GLE is 0 util-15992 DEBUG Freeing memory of connection 0x611898. util-scheduler-15992 DEBUG Running task: 48 / 0x53fe10 util-15992 DEBUG Error receiving: Resource unavailable or operation would block, try again util-15992 DEBUG Timeout in receive_helper, available 0, conn->sock non-NULL, errCode `No error' core-api-15992 INFO Client was disconnected from core service, trying to reconnect. util-scheduler-15992 DEBUG Adding task: 396 / 0x53fe10 util-scheduler-15992 DEBUG Adding task: 397 / 0x53fd60 util-scheduler-15992 DEBUG Running task: 386 / 0x6100c8 util-15992 DEBUG transmit_ready running (0x6100c8). fs-15992 ERROR Assertion failed at connection.c:1453. |
|
|
The issue was introduced by r20246. |
|
|
Actually, i'm not sure why i've picked r20246 as the revision to blame :-/ But r20243 didn't crash - i did check that. |
|
|
00000000001395144334 util-7760 DEBUG transmit_ready running (0x37bf90 on sock 0x37b8a0 (0x214)). I've extended the log message a bit, now it reports SOCKET value as well as the address of the network handle. Now we know that connection 0x37bf90 writes into socket 0x214 via handle 0x37b8a0 00000000001395144453 util-scheduler-7760 DEBUG Running task: 216 / 0x37bf90 00000000001395144453 util-7760 DEBUG transmit_ready running (0x37bf90 on sock 0x37b8a0 (0x214)). 00000000001395144453 util-7760 DEBUG Scheduling transmit_ready (0x37bf90). 00000000001395144453 util-scheduler-7760 DEBUG Adding task: 315 / 0x37bf90 00000000001395144453 util-7760 DEBUG `send' failed at connection.c:1497 with error: Connection reset by peer 00000000001395144453 util-7760 DEBUG Closed 0x214, closesocket() returned 0, GLE is 0 This is where 0x214 is shut down. Now, this is -fs exiting from select(). Note that 0x214 (which is still in write set; why?) is not set in wfds and should not trigger tasks attached to it. And the next call to select() does not feature 0x214 at all (it only selects on 0x194 and 0x1fc, and only for reading). But in the end it STILL runs transmit_ready on connection 0x37bf90, and fails the assertion. 00000000001395144453 util-7760 DEBUG FD 0x28c is SET in rfds 00000000001395144453 util-7760 DEBUG FD 0x2c is SET in rfds 00000000001395144453 util-7760 DEBUG FD 0x8 is NOT SET in rfds 00000000001395144453 util-7760 DEBUG FD 0x278 is NOT SET in rfds 00000000001395144453 util-7760 DEBUG FD 0x218 is NOT SET in rfds 00000000001395144454 util-7760 DEBUG FD 0x290 is NOT SET in wfds 00000000001395144454 util-7760 DEBUG FD 0x288 is NOT SET in wfds 00000000001395144454 util-7760 DEBUG FD 0x214 is NOT SET in wfds 00000000001395144454 util-7760 DEBUG Returning 3 or 0 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 317 / 0x37fca0 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 316 / 0x37fda8 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 315 / 0x37bf90 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 314 / 0x610198 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 101 / 0x60d9f8 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 50 / 0x37bef0 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 42 / 0x37f520 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 3 / 0x618eb0 00000000001395144454 util-scheduler-7760 DEBUG Running task: 101 / 0x60d9f8 00000000001395144454 util-7760 DEBUG Accepting connection on `0.0.0.0:43471' 00000000001395144454 util-7760 WARNING `accept' failed at connection.c:383 with error: Resource unavailable or operation would block, try again 00000000001395144454 util-7760 WARNING `accept' failed at connection.c:383 with error: Resource unavailable or operation would block, try again 00000000001395144454 util-scheduler-7760 DEBUG Adding task: 318 / 0x60d9f8 00000000001395144454 util-scheduler-7760 DEBUG Running task: 42 / 0x37f520 00000000001395144454 util-7760 DEBUG Error receiving: Resource unavailable or operation would block, try again 00000000001395144454 util-7760 DEBUG Timeout in receive_helper, available 0, conn->sock non-NULL, errCode `No error' 00000000001395144454 core-api-7760 INFO Client was disconnected from core service, trying to reconnect. 00000000001395144454 util-scheduler-7760 DEBUG Adding task: 319 / 0x37f520 00000000001395144454 util-scheduler-7760 DEBUG Adding task: 320 / 0x37f268 00000000001395144454 util-7760 DEBUG FD 0x194 (0x62a650) is SET in rfds 00000000001395144454 util-7760 DEBUG FD 0x1fc (0x62a5d8) is SET in rfds 00000000001395144454 util-7760 DEBUG Reading 0 bytes from the pipe 0x194 00000000001395144454 util-7760 DEBUG Adding the pipe's 0x194 overlapped event to the array as 0 00000000001395144454 util-7760 DEBUG Reading 0 bytes from the pipe 0x1fc 00000000001395144454 util-7760 DEBUG Adding the pipe's 0x1fc overlapped event to the array as 1 00000000001395144454 util-7760 DEBUG Adding the socket read event to the array as 2 00000000001395144454 util-7760 DEBUG Adding the socket write event to the array as 3 00000000001395144454 util-7760 DEBUG Number nfds : 45 00000000001395144454 util-7760 DEBUG Number of handles : 4 00000000001395144454 util-7760 DEBUG retcode : 0 00000000001395144454 util-7760 DEBUG Will wait : 0 00000000001395144454 util-7760 DEBUG WaitForMultipleObjects Returned : 258 00000000001395144454 util-7760 DEBUG return pos is : 258 00000000001395144454 util-7760 DEBUG Returning from _select() with nothing! 00000000001395144454 util-7760 DEBUG Zeroing rfds 00000000001395144454 util-7760 DEBUG Zeroing wfds 00000000001395144454 util-7760 DEBUG FD 0x2c is NOT SET in rfds 00000000001395144454 util-7760 DEBUG FD 0x8 is NOT SET in rfds 00000000001395144454 util-7760 DEBUG Returning 0 or 0 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 318 / 0x60d9f8 00000000001395144454 util-scheduler-7760 DEBUG Checking readiness of task: 3 / 0x618eb0 00000000001395144454 util-scheduler-7760 DEBUG Running task: 319 / 0x37f520 00000000001395144454 util-7760 DEBUG Shutting down socket (0x37f520) 00000000001395144454 util-7760 DEBUG Destroy actually runs (0x37f520)! 00000000001395144454 util-7760 DEBUG Closed 0x218, closesocket() returned 0, GLE is 0 00000000001395144454 util-7760 DEBUG Freeing memory of connection 0x37f520. 00000000001395144454 util-scheduler-7760 DEBUG Running task: 50 / 0x37bef0 00000000001395144454 util-7760 DEBUG Error receiving: Resource unavailable or operation would block, try again 00000000001395144454 util-7760 DEBUG Timeout in receive_helper, available 0, conn->sock non-NULL, errCode `No error' 00000000001395144454 util-scheduler-7760 DEBUG Adding task: 321 / 0x37bef0 00000000001395144454 util-scheduler-7760 DEBUG Adding task: 322 / 0x629c90 00000000001395144454 util-scheduler-7760 DEBUG Running task: 314 / 0x610198 00000000001395144454 util-7760 DEBUG receive_ready read 184/65535 bytes from `[::1]:2093' (0x610198)! 00000000001395144454 util-scheduler-7760 DEBUG Adding task: 323 / 0x610288 00000000001395144454 util-scheduler-7760 DEBUG Running task: 315 / 0x37bf90 00000000001395144454 util-7760 DEBUG transmit_ready running (0x37bf90 on sock 0x0 (0xffffffff)). 00000000001395144454 fs-7760 ERROR Assertion failed at connection.c:1453. Here's what gdb says about write set:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x75c7280d in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
(gdb) up
#1 0x61c065a4 in GNUNET_abort () at common_logging.c:271
271 DebugBreak ();
(gdb)
#2 0x61c0f735 in transmit_ready (cls=0x37bf90, tc=0x28fc90) at connection.c:1453
1453 GNUNET_assert (NULL != sock->sock);
(gdb) p sock->sock
$1 = (struct GNUNET_NETWORK_Handle *) 0x0
(gdb) p sock
$2 = (struct GNUNET_CONNECTION_Handle *) 0x37bf90
(gdb) p *tc
$3 = {reason = GNUNET_SCHEDULER_REASON_WRITE_READY, read_ready = 0x378fe8, write_ready = 0x685070}
(gdb) p/x *tc->write_ready
$4 = {nsds = 0x3, sds = {fd_count = 0x3, fd_array = {0x290, 0x288, 0x214, 0x214, 0x284, 0x278, 0x218, 0x214, 0x0 <repeats 1016 times>}}, handles = 0x37b918}
That is, 0x214 suddenly appears as a valid socket in write set. Despite being closed. |
|
|
00000000001401099149 util-scheduler-8488 DEBUG Hooking task 353 to write set 0x278 00000000001401099149 util-scheduler-8488 DEBUG Hooking task 350 to read set 0x288 00000000001401099149 util-scheduler-8488 DEBUG Hooking task 224 to write set 0x284 00000000001401099149 util-scheduler-8488 DEBUG Hooking task 121 to read set 0x8 0x28 00000000001401099149 util-scheduler-8488 DEBUG Hooking task 51 to read set 0x20c 00000000001401099149 util-scheduler-8488 DEBUG Hooking task 43 to read set 0x274 00000000001401099149 util-scheduler-8488 DEBUG Hooking task 3 to read set 0x274 00000000001401099149 util-8488 DEBUG FD 0x194 (0xa8f2b8) is SET in rfds 00000000001401099149 util-8488 DEBUG FD 0x1fc (0xa8f218) is SET in rfds 00000000001401099149 util-8488 DEBUG Reading 0 bytes from the pipe 0x194 00000000001401099149 util-8488 DEBUG Adding the pipe's 0x194 overlapped event to the array as 0 00000000001401099149 util-8488 DEBUG Reading 0 bytes from the pipe 0x1fc 00000000001401099149 util-8488 DEBUG Adding the pipe's 0x1fc overlapped event to the array as 1 00000000001401099149 util-8488 DEBUG Adding the socket read event to the array as 2 00000000001401099149 util-8488 DEBUG Adding the socket write event to the array as 3 00000000001401099149 util-8488 DEBUG pre-send to the socket 0 returned 0 (0) 00000000001401099149 util-8488 DEBUG pre-send to the socket 1 returned -1 (10054) 00000000001401099149 util-8488 DEBUG Number nfds : 649 00000000001401099149 util-8488 DEBUG Number of handles : 4 00000000001401099149 util-8488 DEBUG retcode : 0 00000000001401099150 util-8488 DEBUG Will wait : 70 00000000001401099150 util-8488 DEBUG WaitForMultipleObjects Returned : 2 00000000001401099150 util-8488 DEBUG return pos is : 2 00000000001401099150 util-8488 DEBUG Select retcode : 3 00000000001401099150 util-8488 DEBUG ReadPipes is : 2 00000000001401099150 util-8488 DEBUG Wait for the write event returned 0 00000000001401099150 util-8488 DEBUG send to the socket 0 returned 0 (0) 00000000001401099150 util-8488 DEBUG send to the socket 1 returned -1 (10054) 00000000001401099150 util-8488 DEBUG Zeroing rfds 00000000001401099150 util-8488 DEBUG Zeroing wfds 00000000001401099150 util-8488 DEBUG FD 0x288 is SET in rfds 00000000001401099150 util-8488 DEBUG FD 0x28 is SET in rfds 00000000001401099150 util-8488 DEBUG FD 0x8 is SET in rfds 00000000001401099150 util-8488 DEBUG FD 0x20c is SET in rfds 00000000001401099150 util-8488 DEBUG FD 0x274 is NOT SET in rfds 00000000001401099150 util-8488 DEBUG FD 0x278 is NOT SET in wfds 00000000001401099150 util-8488 DEBUG FD 0x284 is NOT SET in wfds 00000000001401099150 util-8488 DEBUG Returning 5 or 0 00000000001401099150 util-scheduler-8488 DEBUG Checking readiness of task: 353 / 0x4cdab8 00000000001401099150 util-scheduler-8488 DEBUG Checking readiness of task: 350 / 0x48f600 00000000001401099150 util-scheduler-8488 DEBUG Checking readiness of task: 224 / 0x4900c0 00000000001401099150 util-scheduler-8488 DEBUG Checking readiness of task: 121 / 0x48da10 00000000001401099150 util-scheduler-8488 DEBUG Checking readiness of task: 51 / 0xa8fe08 00000000001401099150 util-scheduler-8488 DEBUG Checking readiness of task: 43 / 0xa8b420 00000000001401099150 util-scheduler-8488 DEBUG Checking readiness of task: 3 / 0x498ca8 00000000001401099150 util-scheduler-8488 DEBUG Running task: 224 / 0x4900c0 00000000001401099150 util-8488 DEBUG transmit_ready running (0x4900c0 on sock 0xa8b968 (0x284)). 00000000001401099150 util-8488 DEBUG Scheduling transmit_ready (0x4900c0). 00000000001401099150 util-scheduler-8488 DEBUG Adding task: 354 / 0x4900c0 00000000001401099150 util-8488 DEBUG `send' failed at connection.c:1497 with error: Connection reset by peer 00000000001401218191 util-8488 DEBUG Closed 0x284, closesocket() returned 0, GLE is 0
transmit_ready (void *cls, const struct GNUNET_SCHEDULER_TaskContext *tc)
...
process_notify (sock);
...
RETRY:
ret =
GNUNET_NETWORK_socket_send (sock->sock,
&sock->write_buffer[sock->write_buffer_pos],
have);
if (ret == -1)
{
if (errno == EINTR)
goto RETRY;
LOG_STRERROR (GNUNET_ERROR_TYPE_DEBUG, "send");
MessageBoxA (NULL, "1", "2", 0);
transmit_error (sock);
return;
}
So, this is what's happening: WSA select returns 3 for sockets. We check the write sockets, send on 0x284 returns -1 and sets error to WSAECONNRESET ourt select() returns, putting 0x284 in wfds (the logger is lying, saying that it is not set, as i've just found - logging code for sockets was highly untested, i'll try to fix that later) Scheduler runs transmit_ready, since socket is marked as writable (but it's really disconnected now) transmit_ready() calls process_notify(), which returns a data buffer and schedulers transmit_ready() again. transmit_ready() then proceeds to call send() send() fails and calls transmit_error()
static void
transmit_error (struct GNUNET_CONNECTION_Handle *sock)
{
GNUNET_CONNECTION_TransmitReadyNotify notify;
if (NULL != sock->sock)
{
GNUNET_NETWORK_socket_shutdown (sock->sock, SHUT_RDWR);
GNUNET_break (GNUNET_OK == GNUNET_NETWORK_socket_close (sock->sock));
sock->sock = NULL;
}
if (sock->read_task != GNUNET_SCHEDULER_NO_TASK)
{
GNUNET_SCHEDULER_cancel (sock->read_task);
sock->read_task = GNUNET_SCHEDULER_NO_TASK;
signal_timeout (sock);
return;
}
if (sock->nth.notify_ready == NULL)
return; /* nobody to tell about it */
notify = sock->nth.notify_ready;
sock->nth.notify_ready = NULL;
notify (sock->nth.notify_ready_cls, 0, NULL);
}
transmit_error() makes sure socket is shut down, frees the resources for it and sets sock->sock to NULL. It then calls transmit_ready_callback_wrapper() in server.c, which then calls transmit_to_client() in gnunet-service-fs_lc.c, which just returns 0. Which means that transmit_ready() is STILL scheduled on that socket, even though it is closed and destroyed. And later it runs (why? My guess - because socket is still in a fdset, without its GNUNET_NETWORK_Handle wrapper, and fdset does not know that this socket no longer exists in the system; When select() waits on it, winsock says that socket is invalid, which counts as readiness to write in GNUNET's book) with invalid socket. |
|
|
I'm not sure I follow any of this. Beginning with that I don't see how 'transmit_ready' can still be life after the socket has been closed --- exactly at that time, the 'write_task' should be 0. I'm adding an assertion to confirm this (SVN X). Overall, conneciton.c is still clearly an unholy mess that needs to be cleaned up (see 0002197). Now, I do get a different (possibly related) error in the test_fs_download_indexed, which might be the same error in a different incarnation: Mar 07 19:39:13-911377 util-scheduler-20227 ERROR `select' failed at scheduler.c:849 with error: Bad file descriptor |
|
|
Ui, my new assertion does fail. Fun. Mar 07 21:31:39-668168 datastore-30589 ERROR Assertion failed at connection.c:1391. |
|
|
Ok, I found that the call to 'process_notify' was to blame for backhandedly adding another write task. Fixed in SVN 20357. Please let me know if this fixes your original issue as well. |
|
|
This fixes my original issue as well. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-03-06 14:05 | LRN | New Issue | |
| 2012-03-06 14:15 | LRN | Note Added: 0005570 | |
| 2012-03-06 14:28 | LRN | Note Added: 0005571 | |
| 2012-03-06 18:03 | LRN | Note Added: 0005573 | |
| 2012-03-07 10:48 | LRN | Note Added: 0005574 | |
| 2012-03-07 11:02 | LRN | Note Added: 0005575 | |
| 2012-03-07 13:19 | LRN | Note Added: 0005577 | |
| 2012-03-07 19:55 | Christian Grothoff | Note Added: 0005579 | |
| 2012-03-07 21:36 | Christian Grothoff | Note Added: 0005580 | |
| 2012-03-07 21:40 | Christian Grothoff | Note Added: 0005581 | |
| 2012-03-08 12:42 | LRN | Note Added: 0005582 | |
| 2012-03-08 13:17 | Christian Grothoff | Status | new => resolved |
| 2012-03-08 13:17 | Christian Grothoff | Fixed in Version | => 0.9.3 |
| 2012-03-08 13:17 | Christian Grothoff | Resolution | open => fixed |
| 2012-03-08 13:17 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2012-03-08 13:17 | Christian Grothoff | Product Version | Git master => 0.9.2 |
| 2012-03-08 13:17 | Christian Grothoff | Target Version | => 0.9.3 |
| 2012-06-02 19:15 | Christian Grothoff | Status | resolved => closed |
