Please die if you wait "too long" RtlpWaitForCriti

[Dee Ayy]

I'm receiving the following error in a custom app:

err:ntdll:RtlpWaitForCriticalSection section 0x110048 "heap.c: main
process heap section" wait timed out in thread 001a, blocked by 001c,
retrying (60 sec)
wine: Critical section 00110048 wait failed at address 0x7bc3ad00
(thread 001a), starting debugger...
err:ntdll:RtlpWaitForCriticalSection section 0x110048 "heap.c: main
process heap section" wait timed out in thread 001a, blocked by 001c,
retrying (60 sec)
err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr
0x7bc3ad00

I hoped an upgrade to 1.1.3 would fix it but I still get the error.

This post http://www.winehq.org/pipermail/wine-de ... 13670.html
seems to confirm that it is just a thread that is waiting. And google
reports that many professional apps also have this error.

This is for a time dependent application. If the thread waits too
long, say 5 seconds, then I'd really just appreciate if it would die
rather than continue to wait. Can I tell the thread to die if it
waits too long? And my time limit, not 60 sec?

A scarier problem may be that any future thread will also fail if
somehow some critical section is not being flagged as
released/unlocked. How can I insure that it gets unlocked?
In fact, how can I find out where this critical section is so that I
might control locks? I would guess here that I need winedbg, but how
would I debug my time-dependent app? Apparently I need to handle some
exception?

With gdb for C (even for a time dependent app), I compile with "cc
-g", wait for a core dump, use gdb myApp core, then type "where". But
the wine app is in C++.

I don't know how important this is, but I could swear that my exe
complained about ntdll.dll missing, so I dropped in the MS version in
the exe directory and placated that.
I found something yesterday that said the native ntdll.dll should
never be used. So I removed it (or rather renamed it), and I don't
get the complaint about ntdll that I thought I recalled a long while
ago about needing it, but I still get the RtlpWaitForCriticalSection
error.

Thanks.

[jeffz]

How can I insure that it gets unlocked?

What you describe indicates that something has gone wrong because a critical section has not been released in a reasonable amount of time. Normally one might be entered for a few milliseconds, if that.

Try turning on debug flags to look at the logs to see what calls have been made but have not returned before the RtlpWaitForCritic... message appears.

What is the program?

[vitamin]

This is for a time dependent application. If the thread waits too
long, say 5 seconds, then I'd really just appreciate if it would die
rather than continue to wait. Can I tell the thread to die if it
waits too long? And my time limit, not 60 sec?

No this is impossible. If you do that most every program will brake.

[Dee Ayy]

On Sun, Aug 24, 2008 at 9:10 PM, jeffz <[email protected]> wrote:

What you describe indicates that something has gone wrong because a critical section has not been released in a reasonable amount of time. Normally one might be entered for a few milliseconds, if that.

Try turning on debug flags to look at the logs to see what calls have been made but have not returned before the RtlpWaitForCritic... message appears.

I invoke myexe like this:
echo "some stuff" | wine myexe

If I just try 'echo "some stuff" | winedbg myexe', I get
WineDbg starting on pid 0016
Fontconfig error: Cannot load default config file
0x7b8780b2: movl %esi,0x0(%esp)
Wine-dbg>syntax error
Syntax Error (#)
Wine-dbg>MyUbuntuPrompt$

I actually get "Fontconfig error: Cannot load default config file"
TWICE with just 'echo "some stuff" | wine myexe' and I don't think I
need fonts for this app. After that it runs fine except for the
err:ntdll:RtlpWaitForCriticalSection which happens a while later.

When I tried 'echo "some stuff" | WINEDEBUG=+all myexe'
my app did not terminate, but it froze when it should have been
displaying updated information.

What is the program?

This is a custom forex trading app based on this API
http://www.metaquotes.net/files/mtapi.zip
Basically the app:
1) Makes a message only window to receive updated quotes.
2) Makes a server to listen for client commands to place orders

[Dee Ayy]

On Sun, Aug 24, 2008 at 9:14 PM, vitamin <[email protected]> wrote:

No this is impossible. If you do that most every program will brake.

So what steps can I take to avoid this error?

[vitamin]

On Sun, Aug 24, 2008 at 9:14 PM, vitamin <[email protected]> wrote:

No this is impossible. If you do that most every program will brake.

So what steps can I take to avoid this error?

It can only work from cmd.exe. However I'm not sure if it's properly implemented there yet.
Of course your app have to be console app not gui.

[Dee Ayy]

On Sun, Aug 24, 2008 at 10:33 PM, vitamin <[email protected]> wrote:

It can only work from cmd.exe. However I'm not sure if it's properly implemented there yet.
Of course your app have to be console app not gui.

My app is console. But this is an MSVC++ compiled app which runs on
MS Windows cmd.exe and GNU bash shell using wine.

[vitamin]

On Sun, Aug 24, 2008 at 10:33 PM, vitamin <[email protected]> wrote:

It can only work from cmd.exe. However I'm not sure if it's properly implemented there yet.
Of course your app have to be console app not gui.

My app is console. But this is an MSVC++ compiled app which runs on
MS Windows cmd.exe and GNU bash shell using wine.

Try:

Code: Select all

$ wine cmd
c:> echo "some stuff" | myexe

[Dee Ayy]

On Mon, Aug 25, 2008 at 12:44 AM, vitamin <[email protected]> wrote:

Try:

Code:
$ wine cmd
c:> echo "some stuff" | myexe

Interesting way to run wine. However, I get the same response.

Was that supposed to die if I got RtlpWaitForCriticalSection? By the
way, the app just hung. It did not return to the cmd prompt until I
hit the carriage return key.

I may not have been clear. I don't want the whole app to die, I just
want the thread to die if it has to wait.

In case I need more debug logs, how can I do the following from cmd.exe?
From bash shell I do this:
(((echo "some stuff" | wine myexe | tee stdout.txt) 3>&1 1>&2 2>&3 |
tee stderr.txt) 3>&1 1>&2 2>&3) > mypipe 2>&1
But I don't think cmd.exe likes pipes nor redirection.

I'd hate to have to resort to splitting myexe into two exe's so that I
can see if the problem is in the quote section or the ordering section
(UNLESS THERE IS A WINEDEBUG FLAG I CAN DECIPHER). Also, if only the
ordering part is dying, maybe an app monitoring program can restart
that for me.

[Dee Ayy]

On Sun, Aug 24, 2008 at 8:36 PM, Dee Ayy <[email protected]> wrote:

I'm receiving the following error in a custom app:

err:ntdll:RtlpWaitForCriticalSection section 0x110048 "heap.c: main
process heap section" wait timed out in thread 001a, blocked by 001c,
retrying (60 sec)

Ahh, the heap.c seems to be from ::HeapFree
http://msdn.microsoft.com/en-us/library ... S.85).aspx

This is now a C++ question. What's wrong with this code? I'm only
calling ::HeapFree if I have a valid pointer on which to call it, no?
A window message is handled with this code, and I would expect that it
is the only window message being processed at this time. If that is
not the case, is there a way to "ensure serialized access" at this
point? I did not write GetTradeRecords. For example, Java has a
"synchronized" block level command that I could just enclose the code
below into a code block.

if (g_pTrades != NULL)
::HeapFree(hHeap, 0, g_pTrades);

BriefUserInfo bui;
::ZeroMemory(&bui, sizeof(bui));
int g_nTrades = 0;
std::string str;
std::string symbol;
g_pTrades = apiPumping.GetTradeRecords(&bui, &g_nTrades);
...
if (g_pTrades != NULL)
::HeapFree(hHeap, 0, g_pTrades);

//Mental note: Add more debug assertions.

[vitamin]

On Mon, Aug 25, 2008 at 12:44 AM, vitamin <[email protected]> wrote:

Try:

Code:
$ wine cmd
c:> echo "some stuff" | myexe

Interesting way to run wine. However, I get the same response.

Then either your program is buggy or Wine's cmd doesn't fully implement what you want.

Making a simple test app points ... to your app being buggy:

Code: Select all

#include <stdio.h>

int main(void)
{
    char buff[100];
    fgets(buff, sizeof(buff), stdin);
    printf("got "%s"\n", buff);
    return 0;
}

$ i386-mingw32-gcc test_pipe.c -o test_pipe.exe
$ echo "something" | wine test_pipe.exe
got "something
"
$ wine cmd
CMD Version 1.1.3

C:\>echo "something" | test_pipe.exe
got ""something"
"
C:\>

[Dee Ayy]

On Wed, Aug 27, 2008 at 1:08 AM, vitamin <[email protected]> wrote:
Code like what you posted works.
What does not work apparently is tee and 3>&1 1>&2 2>&3

Yes there were bugs and something I don't understand.
1) My logic bug: There was no need to call the following before my
code block -- I thought I was being cautious. (The MTAPI says to call
it after). My app seems to be working fine now without this initial
HeapFree.
if (g_pTrades != NULL)
::HeapFree(hHeap, 0, g_pTrades);

2) I don't understand why there is a problem having what I thought was
a safety HeapFree call since I'm checking that g_pTrades != NULL.
From MSDN If this pointer is NULL, the behavior is undefined.
But the if statement should guard for that. No?
I'm not even going to bother putting in braces for the "after" call,
but I'm not understanding why I seemed to be getting heap corruption
(when I had the "before" call) when I'm not even supposed to be
calling it due to the guarded if statement. From MSDN Calling
HeapFree twice with the same pointer can cause heap corruption
if (g_pTrades != NULL){
::HeapFree(hHeap, 0, g_pTrades);
}

[vitamin]

On Wed, Aug 27, 2008 at 1:08 AM, vitamin <[email protected]> wrote:
Code like what you posted works.
What does not work apparently is tee and 3>&1 1>&2 2>&3

Yes there were bugs and something I don't understand.
1) My logic bug: There was no need to call the following before my
code block -- I thought I was being cautious. (The MTAPI says to call
it after). My app seems to be working fine now without this initial
HeapFree.
if (g_pTrades != NULL)
::HeapFree(hHeap, 0, g_pTrades);

The check for NULL is extra. HeepFree (same as normal free() ) ignores NULL pointers. So most likely you are freeing something you did not allocate.
Or as you said - freeing something twice. HeepFree (as well as normal free) does not modify the passed in pointer.