Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Access Violation on a thread
60 views
Skip to first unread message
Christopher Pisz
Jan 27, 2015, 1:54:51 PM1/27/15
to
Is there some defined standard behavior about what should happen should
an Access Violation occur on a thread?
My application is single threaded, and I see in my debugger it has 12 or
so threads with COM and RPC and wininet crap. Everything in those
threads is completely outside of my source. So, I assume some third
party library (gsoap) is creating these threads. Randomly I get an
Access Violation on one or more of these threads.
Should I expect the process to terminate?
or
Should the thread terminate on its own?
What is expected to happen if this occurs?
an Access Violation occur on a thread?
My application is single threaded, and I see in my debugger it has 12 or
so threads with COM and RPC and wininet crap. Everything in those
threads is completely outside of my source. So, I assume some third
party library (gsoap) is creating these threads. Randomly I get an
Access Violation on one or more of these threads.
Should I expect the process to terminate?
or
Should the thread terminate on its own?
What is expected to happen if this occurs?
Paavo Helde
Jan 27, 2015, 2:34:58 PM1/27/15
to
Christopher Pisz <nos...@notanaddress.com> wrote in news:ma8mse$gv4$1
@dont-email.me:
Access violation is most usually caused by the program invoking Undefined
Behavior, so anything can happen. Typically, in Linux world you could be
pretty certain the process is killed in spot by the OS. However, in
Windows world this is not so simple, the program can define handlers for
"handling" these kind of errors. Windows also likes to display (mostly
unhelpful) dialog boxes, sometimes offering a possibility to attach a
debugger. As "anything can happen", all these behaviors are legal.
Terminating a single thread is not an option as this is pretty much
guaranteed to leave the process in an inconsistent state.
Another a bit more reliable way is to "handle and ignore" the error,
there are even Windows SDK idioms which actually do that in an
encapsulated way (IsBadReadPtr() and friends) which can be greatly abused
by crappy programs for hiding their bugs. If you can continue the program
in the debugger after the access violation and nothing bad seems to
happen, this probably means the code has "handled" the access violation
in this or a similar way.
Note that even if the problem appears in a foreign thread it does not
mean that your code is not to blame. It could have passed some invalid
data to the foregin thread directly or indirectly.
hth
Paavo
@dont-email.me:
Behavior, so anything can happen. Typically, in Linux world you could be
pretty certain the process is killed in spot by the OS. However, in
Windows world this is not so simple, the program can define handlers for
"handling" these kind of errors. Windows also likes to display (mostly
unhelpful) dialog boxes, sometimes offering a possibility to attach a
debugger. As "anything can happen", all these behaviors are legal.
Terminating a single thread is not an option as this is pretty much
guaranteed to leave the process in an inconsistent state.
Another a bit more reliable way is to "handle and ignore" the error,
there are even Windows SDK idioms which actually do that in an
encapsulated way (IsBadReadPtr() and friends) which can be greatly abused
by crappy programs for hiding their bugs. If you can continue the program
in the debugger after the access violation and nothing bad seems to
happen, this probably means the code has "handled" the access violation
in this or a similar way.
Note that even if the problem appears in a foreign thread it does not
mean that your code is not to blame. It could have passed some invalid
data to the foregin thread directly or indirectly.
hth
Paavo
Robert Wessel
Jan 27, 2015, 2:55:06 PM1/27/15
to
concerned, so no help there.
Windows will by default terminate a process if any of its threads
abend. But the application can have code to catch* (not in the C++
sense) traps, and if it does, pretty much anything can happen again.
Other OSs are usually similar (*nix, for example), although there are
variances (using the traditional "ATTACH" mechanism to implement
threads in MVS, for example, creates something that's halfway between
a process and a thread, and the attached process/thread can abend
without the other processes/threads getting killed, although there is
a notification).
*One possibility is Windows' structured exception handling (SEH)
Robert Wessel
Jan 27, 2015, 3:03:01 PM1/27/15
to
On Tue, 27 Jan 2015 13:34:46 -0600, Paavo Helde
<myfir...@osa.pri.ee> wrote:
>Christopher Pisz <nos...@notanaddress.com> wrote in news:ma8mse$gv4$1
>@dont-email.me:
>
>> Is there some defined standard behavior about what should happen should
>> an Access Violation occur on a thread?
>>
>> My application is single threaded, and I see in my debugger it has 12
>or
>> so threads with COM and RPC and wininet crap. Everything in those
>> threads is completely outside of my source. So, I assume some third
>> party library (gsoap) is creating these threads. Randomly I get an
>> Access Violation on one or more of these threads.
>>
>> Should I expect the process to terminate?
>> or
>> Should the thread terminate on its own?
>>
>> What is expected to happen if this occurs?
>
>Access violation is most usually caused by the program invoking Undefined
>Behavior, so anything can happen. Typically, in Linux world you could be
>pretty certain the process is killed in spot by the OS.
Well, unless the application set up a SIGSEGV or SIGBUS handler.
<myfir...@osa.pri.ee> wrote:
>Christopher Pisz <nos...@notanaddress.com> wrote in news:ma8mse$gv4$1
>@dont-email.me:
>
>> Is there some defined standard behavior about what should happen should
>> an Access Violation occur on a thread?
>>
>> My application is single threaded, and I see in my debugger it has 12
>or
>> so threads with COM and RPC and wininet crap. Everything in those
>> threads is completely outside of my source. So, I assume some third
>> party library (gsoap) is creating these threads. Randomly I get an
>> Access Violation on one or more of these threads.
>>
>> Should I expect the process to terminate?
>> or
>> Should the thread terminate on its own?
>>
>> What is expected to happen if this occurs?
>
>Access violation is most usually caused by the program invoking Undefined
>Behavior, so anything can happen. Typically, in Linux world you could be
>pretty certain the process is killed in spot by the OS.
Martijn Lievaart
Jan 28, 2015, 3:10:14 AM1/28/15
to
sane OS your app is terminated (unless it chooses to catch the violation,
but that is unlikely and very rare).
I want to chime in that your next course of action should be to determine
if:
1) The library is crap and (from the library users POV) randomly crashes.
Unlikely, but would certainly not be the first => Scrap the library and
get another.
2a) The parameter validation of the library leaves to be desired and you
pass it invalid parameters. Very well possible and probably hard to debug
=> Either pass it correct parameters or get a better library
2a) You pass the library invalid parameters which it cannot validate.
Very well possible and probably hard to debug => Pass it correct
parameters or get a library with a simpler API that can validate it's
parameters.
3) Something other. Still quite likely. => Rule it out or solve it.
My money is on 2a, possibly 2b.
If the offender is gsoap, you're lucky. It's FOSS, so create a debug
build and run it under a debugger. That should answer this question (note
that I did not say this would be easy)
Goed luck!
M4
Christopher Pisz
Jan 28, 2015, 6:46:12 PM1/28/15
to
with it and couldn't get the simplest of communication to compile and
complete. In production code it is used in some manner that doesn't look
like any example I've ever seen online. The docs for it just stink.
Results are not what they say they are. I am at the point where I am
collecting evidence to support dropping it and using something else.
I've always went the route of "if it takes longer to figure out then to
write it over, hit delete"
jacob navia
Jan 29, 2015, 8:11:21 AM1/29/15
to
Le 29/01/2015 00:46, Christopher Pisz wrote:
>
> I downloaded the latest GSoap and tried to do a separate test scenario
> with it and couldn't get the simplest of communication to compile and
> complete. In production code it is used in some manner that doesn't look
> like any example I've ever seen online. The docs for it just stink.
> Results are not what they say they are. I am at the point where I am
> collecting evidence to support dropping it and using something else.
> I've always went the route of "if it takes longer to figure out then to
> write it over, hit delete"
>
Did you READ this?
>
> I downloaded the latest GSoap and tried to do a separate test scenario
> with it and couldn't get the simplest of communication to compile and
> complete. In production code it is used in some manner that doesn't look
> like any example I've ever seen online. The docs for it just stink.
> Results are not what they say they are. I am at the point where I am
> collecting evidence to support dropping it and using something else.
> I've always went the route of "if it takes longer to figure out then to
> write it over, hit delete"
>
GSOAP License:
WARRANTY
YOU ACKNOWLEDGE THAT THE SOFTWARE IS PROVIDED "AS IS" AND THAT
GENIVIA INC. DO NOT WARRANT THE SOFTWARE WILL RUN UNINTERRUPTED OR ERROR
FREE.
LIMITED LIABILITY: THE ENTIRE RISK AS TO RESULTS AND PERFORMANCE OF THE
SOFTWARE IS ASSUMED BY YOU.
So stop wasting your time here and call your support representative.
What?
You didn't buy support?
Well then...
YOU GET WHAT YOU PAY FOR!
Christopher Pisz
Jan 29, 2015, 10:56:14 AM1/29/15
to
know what's wrong with it....It's garbage. Any library that doesn't even
have a reference where I can look up each individual function, class,
and method, is garbage. All it has is a long document with examples that
don't work and concept explanations. I am asking about the behavior to
expect with an access violation on another thread, since it surprised me
to see an access violation occur repeatedly without the process crashing.
Paavo Helde
Jan 29, 2015, 12:06:11 PM1/29/15
to
Christopher Pisz <nos...@notanaddress.com> wrote in
news:madl5i$cn$1...@dont-email.me:
> I am asking
> about the behavior to expect with an access violation on another
> thread, since it surprised me to see an access violation occur
> repeatedly without the process crashing.
code) and appears to cause no harm, then this is probably "by design" and
there is nothing you can do about it (except installing another OS of
course).
Cheers
Paavo
Robert Wessel
Feb 2, 2015, 7:57:27 PM2/2/15
to
On Wed, 28 Jan 2015 09:05:57 +0100, Martijn Lievaart
<m...@rtij.nl.invlalid> wrote:
>On Tue, 27 Jan 2015 12:54:38 -0600, Christopher Pisz wrote:
>
>> Is there some defined standard behavior about what should happen should
>> an Access Violation occur on a thread?
>>
>> My application is single threaded, and I see in my debugger it has 12 or
>> so threads with COM and RPC and wininet crap. Everything in those
>> threads is completely outside of my source. So, I assume some third
>> party library (gsoap) is creating these threads. Randomly I get an
>> Access Violation on one or more of these threads.
>>
>> Should I expect the process to terminate?
>> or Should the thread terminate on its own?
>>
>> What is expected to happen if this occurs?
>
>As others pointed out anything is allowed to happen, but on any modern
>sane OS your app is terminated (unless it chooses to catch the violation,
>but that is unlikely and very rare).
In my experience, it's not very rare at all. YMMV.
<m...@rtij.nl.invlalid> wrote:
>On Tue, 27 Jan 2015 12:54:38 -0600, Christopher Pisz wrote:
>
>> Is there some defined standard behavior about what should happen should
>> an Access Violation occur on a thread?
>>
>> My application is single threaded, and I see in my debugger it has 12 or
>> so threads with COM and RPC and wininet crap. Everything in those
>> threads is completely outside of my source. So, I assume some third
>> party library (gsoap) is creating these threads. Randomly I get an
>> Access Violation on one or more of these threads.
>>
>> Should I expect the process to terminate?
>> or Should the thread terminate on its own?
>>
>> What is expected to happen if this occurs?
>
>As others pointed out anything is allowed to happen, but on any modern
>sane OS your app is terminated (unless it chooses to catch the violation,
>but that is unlikely and very rare).
Öö Tiib
Feb 2, 2015, 11:11:10 PM2/2/15
to
handles Windows SEH exceptions and so prevents operating system from
terminating crashed process.
Handling SEH exceptions can be handy to terminate application and to
report defect without windows GUI message boxes about the crash (not
all applications have GUI). It can not be a tool for "fixing" defects.
0 new messages