Home > Archive > Visual Studio > March 2005 > fopen problem, possibly LeaveCriticalSection
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
fopen problem, possibly LeaveCriticalSection
|
|
| James Whitwell 2004-12-01, 8:58 pm |
| Hi,
We've been receiving bug reports from users. The minidumps we've been
getting back say
Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
[rethrow] @ 0x00000000
and the following call stack:
KERNEL32.DLL 7c57e592()
KERNEL32.DLL 7c57e592()
msvcr71.dll __unlock() + 0x13
msvcr71.dll __unlock_file() + 0x22
msvcr71.dll __fsopen() + 0x5a
The kernel32.dll addresses seem to be that the call to __unlock() does this
LeaveCriticalSection( _locktable[locknum].lock );
Does anyone know what this is, and why it'd be failing? It only happens
intermittently; never on my machine, always on a users'.
Thanks,
;) james.
| |
| wh0cares 2004-12-03, 8:56 am |
|
"James Whitwell" <jams@NO_SPAMmomento.com.au> wrote in message
news:#XJkRSA2EHA.2600@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> We've been receiving bug reports from users. The minidumps we've been
> getting back say
>
> Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
> [rethrow] @ 0x00000000
>
> and the following call stack:
>
> KERNEL32.DLL 7c57e592()
> KERNEL32.DLL 7c57e592()
> msvcr71.dll __unlock() + 0x13
> msvcr71.dll __unlock_file() + 0x22
> msvcr71.dll __fsopen() + 0x5a
>
> The kernel32.dll addresses seem to be that the call to __unlock() does
this
>
> LeaveCriticalSection( _locktable[locknum].lock );
>
> Does anyone know what this is, and why it'd be failing? It only happens
> intermittently; never on my machine, always on a users'.
>
> Thanks,
> ;) james.
Hi James
Firstly I think you are tackling the problem in the wrong way. Your priority
should be to recreate the crash in your test environment. If you can't
future bugs will not be captured!
Secondly I think you are looking in the wrong place. I am guessing that the
LeaveCriticalSection() function is working but is being passed invalid
data/thread/object/pointer. I am also guessing that LeaveCriticalSection()
is a lot lower level than your code. So look further up the chain eg do you
check if the object has been created properly or if your locknum is going
out of bounds.
With out more information it is hard to offer more advice.
Some quick ideas
1) Get the user (the one who crashes the most) to talk you through how they
use your app (you will be surprised). This might lead you thorough the
route to a crash
2) Ask to borrow one of users pcs to try and recreate the crash with real
data and settings.
3) Release a debug version which logs all the key events. I personally use a
debug function instead of comments in my files. All it does is write a line
to a text file if a debug environment variable has been defined. Create the
file name using the data and time for a unique name and if space is an issue
delete the file when the app closes that way you will only have records of
the crashes.
4) A good question to ask users is "I bet you get IT people down here a
lot?" , it gets a more honest answer than asking "what have you changed on
the system?".
Hope that help
GS
| |
| Alexander Grigoriev 2004-12-07, 4:16 am |
| Make sure all your components are linked against the same msvcr71.dll.
Also don't use catch(...). Use SetUnhandledExceptionFilter instead.
"James Whitwell" <jams@NO_SPAMmomento.com.au> wrote in message
news:%23XJkRSA2EHA.2600@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> We've been receiving bug reports from users. The minidumps we've been
> getting back say
>
> Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
> [rethrow] @ 0x00000000
>
> and the following call stack:
>
> KERNEL32.DLL 7c57e592()
> KERNEL32.DLL 7c57e592()
> msvcr71.dll __unlock() + 0x13
> msvcr71.dll __unlock_file() + 0x22
> msvcr71.dll __fsopen() + 0x5a
>
> The kernel32.dll addresses seem to be that the call to __unlock() does
> this
>
> LeaveCriticalSection( _locktable[locknum].lock );
>
> Does anyone know what this is, and why it'd be failing? It only happens
> intermittently; never on my machine, always on a users'.
>
> Thanks,
> ;) james.
| |
| James Whitwell 2004-12-07, 4:16 am |
| Hi,
Thanks for a great reply. It's always good to hear someone else's
debugging tips.
wh0cares wrote:
> Firstly I think you are tackling the problem in the wrong way. Your priority
> should be to recreate the crash in your test environment. If you can't
> future bugs will not be captured!
That's the crux really: I can't figure out how to reproduce it. When I
look at the call stack, it starts in my code with a call to fopen(),
which goes into msvcr71.dll as __fsopen, then __unlock_file(), then
__unlock(), and finally into kernel32.dll as LeaveCriticalSection(). So
the call to LeaveCriticalSection() isn't actually in my code.
What I'm wondering is if anyone has any ideas on how this bug might be
tripped. The error that I see (from the minidump that's produced when
the program crashes on the user's machine) is
Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
[rethrow] @ 0x00000000.
Is it possible I'm eventually running out of something internal to the C
runtime library, by not closing all my open FILE handles, or something?
I tried opening as many filehandles as possible, then closing random
ones, then opening more, but I couldn't trip it up.
thanks,
;) james.
| |
| greg_dolley 2005-03-29, 12:47 am |
| quote:
Originally posted by James Whitwell
Hi,
We've been receiving bug reports from users. The minidumps we've been
getting back say
Unhandled exception at 0x7c57e592 in CRASH.DMP: Microsoft C++ exception:
[rethrow] @ 0x00000000
and the following call stack:
KERNEL32.DLL 7c57e592()
KERNEL32.DLL 7c57e592()
msvcr71.dll __unlock() + 0x13
msvcr71.dll __unlock_file() + 0x22
msvcr71.dll __fsopen() + 0x5a
The kernel32.dll addresses seem to be that the call to __unlock() does this
LeaveCriticalSection( _locktable[locknum].lock );
Does anyone know what this is, and why it'd be failing? It only happens
intermittently; never on my machine, always on a users'.
Thanks,
;) james.
James,
You're getting this problem most likely due to the problem in Microsoft's version of the C runtime stdio lib. I've found that fopen() and fgetc() sometimes return EOF when in fact it's really NOT the end of the file and no error has occured. Your program probably called fopen with no error, but later called fgetc and it returned EOF for the first char. Yet your program thinks everything is OK since fopen returned success. This contradiction in return values has caused my programs some problems. There are a couple ways to solve this:
1) I see you're using Microsoft's runtime lib - err, fopen() should NOT be calling _fsopen(), but MS does it anyway. Nothing much you can do about that except link your prog with Boreland's stdlib, and use MS for all the other libs. This would only work if you're programming plain ANSI C, or plain C++.
2) If fgetc() returns EOF (-1) after fopen() returned success, close the file handle with fclose() and try reopening the file again. When you call fgetc() again, it will behave correctly.
The only time I've found this phenomenon occuring is when I open a file that is being written to by some other process at the same time. With the way fopen() should REALLY work, is it should give an error when you try to open a file that's already open by another process. The whole reason _fsopen() exists is to do _shared_ file opening instead of regular file opening with fopen(). Why Microsoft calls _fsopen() in their C runtime is beyond me. Besides, did you know _fsopen() is specific to DOS, while fopen() is ANSI C?
I wish I had a better solution for you, but at least now you probably know why your problem is occuring.
-Greg Dolley |
|
|
|
|