Asynchronous routine call leads to crash

[Night-walker]

routine f(){}
f()!!

SIGSEGV upon exiting.

[daokoder]

Odd. It works for me. Which system, Windows?

[Night-walker]

Yes, it's again Windows. It seems DaoVM crashes upon exiting if that code was executed earlier (tried in the interactive mode via GDB). SIGSEGV happens somewhere in ntdll or so, most likely an issue with freeing some thread-related stuff.

[Night-walker]

By the way, it is very strange that during the executing of the given code DCondVar_TimedWait() was called 3204 times. I seriously doubt it is normal behavior.

[daokoder]

Fixed, it was a simple bug.

Do you have a profile to show where DCondVar_TimedWait() is called most?

[Night-walker]

Do you have a profile to show where DCondVar_TimedWait() is called most?

I don't have much skills with GDB, but it seems most calls are one of these three:

Breakpoint 1, DCondVar_TimedWait (self=0xa31cd0, mtx=0xa31c98, seconds=0.01)
    at kernel/daoThread.c:265

#0  DCondVar_TimedWait (self=0xa31cd0, mtx=0xa31c98, seconds=0.01)
    at kernel/daoThread.c:265
        retc = 258
        p = (DThreadData *) 0x244430
#1  0x6f05b1f6 in DaoCallServer_Timer (p=0x0) at kernel/daoTasklet.c:363
        server = (DaoCallServer *) 0xa31c60
        time = 0
        i = 8
        timeout = 15597336
#2  0x6f0733db in DThread_Wrapper (object=0xa31c60) at kernel/daoThread.c:335
        self = (DThread *) 0xa31c60
#3  0x77c2a243 in msvcrt!_endthread () from C:\WINDOWS\system32\msvcrt.dll

Breakpoint 1, DCondVar_TimedWait (self=0x6f09a160, mtx=0x6f09a100,
    seconds=6.8657125718003672e+226) at kernel/daoThread.c:265

#0  DCondVar_TimedWait (self=0x6f09a160, mtx=0x6f09a100,
    seconds=6.8657125718003672e+226) at kernel/daoThread.c:265
        retc = 258
        p = (DThreadData *) 0x244368
#1  0x6efc9571 in DaoCGC_Recycle (p=0x0) at kernel/daoGC.c:1168
        gcount = 5
        wtime = 0.0099977502531060167
        works = (DArray *) 0x3e27a0
        idles = (DArray *) 0x3e2778
        works2 = (DArray *) 0x3e27f0
        idles2 = (DArray *) 0x3e27c8
        frees = (DArray *) 0x3e2840
        delays = (DArray *) 0x3e2818
        N = 0
#2  0x6f0733db in DThread_Wrapper (object=0x6f09a0b0)
    at kernel/daoThread.c:335
        self = (DThread *) 0x6f09a0b0
#3  0x77c2a243 in msvcrt!_endthread () from C:\WINDOWS\system32\msvcrt.dll

Breakpoint 1, DCondVar_TimedWait (self=0xa31cb0, mtx=0xa31c98, seconds=0.001)
    at kernel/daoThread.c:265

#0  DCondVar_TimedWait (self=0xa31cb0, mtx=0xa31c98, seconds=0.001)
    at kernel/daoThread.c:265
        retc = 258
        p = (DThreadData *) 0x244488
#1  0x6f05c6ee in DaoCallThread_Run (self=0xa23468) at kernel/daoTasklet.c:799
        process = (DaoProcess *) 0x0
        future = (DaoFuture *) 0x0
        function = (DThreadTask) 0
        parameter = (void *) 0x0
        server = (DaoCallServer *) 0xa31c60
        wt = 0.001
        i = 0
        count = 0
        timeout = 1
#2  0x6f0733db in DThread_Wrapper (object=0xa23468) at kernel/daoThread.c:335
        self = (DThread *) 0xa23468
#3  0x77c2a243 in msvcrt!_endthread () from C:\WINDOWS\system32\msvcrt.dll

[daokoder]

It seems to be a windows specific problem. On Linux, it is only called 5 times!

I will check it on windows to see what's going on.

[daokoder]

Are you sure it was called that many times? I used gprof to check on windows xp, it turned out to be called only 7 times. I compiled and tested Dao using MinGW in the MSYS environment.

[Night-walker]

I used a variable to count. And printf(), too -- the latter dumped endless stream of messages. Compiled under MinGW on Windows XP, tried both normal and debug build.

[daokoder]

I also tried printf(), it printed only a few times. My MinGW installation uses GCC 4.6.1. I ran Windows XP inside VirtualBox. Do you run it natively?

[Night-walker]

Yes, I run it all natively, first under GCC 4.4 and now under 4.8. The while loops in DaoCallThread_Run() and DaoCallServer_Timer() which call DCondVar_TimedWait() are executed hundreds of times.

There is line printf( "%p %i %i %i %i\n", self, server->events->size, server->pending->size, server->events2->size, server->waitings->size ); which looks like a debugging message. For me it indefinitely prints one of two addresses for self and four zeroes for other arguments.

[daokoder]

Probably, the threading library behaves quite differently in native Windows. Unfortunately, I have no access to native Windows system on which I can test this:(.

Do you have access to any other native Windows system? I wonder if this behavior is consistent in all native Windows systems (or all XP).

[Night-walker]

I also wonder about that. I'll try it on another machine soon.

[Night-walker]

Same situation on another machine on Windows 7.

[Night-walker]

It is not related to Windows -- I have the same thing on Linux!

[daokoder]

That's weird, do you have a clean setup? Did you test it with a clean clone from the github repository?

[Night-walker]

I know the reason. I ran the code in the interactive mode. Putting it in file makes DCondVar_TimedWait() be called just 6 times.

[daokoder]

I see. Then this is not a bug. The following line from DaoCallThread_Run() is responsible for most DCondVar_TimedWait() calls:

timeout = DCondVar_TimedWait( & server->condv, & server->mutex, wt );

Here wt = 0.001, so if you quit the interactive mode in 5 seconds, this DCondVar_TimedWait() will be called approximately 5000 times. This small waiting time is set to make the scheduling more responsive to available events, just in case that the condition variable signaling for such events is not well responded by the threads for any reason.

[Night-walker]

So much buzz around such a trifle... OK, all's working fine, issue closed.