Graceful Crash on Bad Pointer

This is a discussion on Graceful Crash on Bad Pointer within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by Elysia Well, I suppose it's easy to make a mistake between This program has stopped responding and ...

  1. #16
    Registered User
    Join Date
    Jun 2005
    Posts
    6,163
    Quote Originally Posted by Elysia View Post
    Well, I suppose it's easy to make a mistake between
    This program has stopped responding and needs to be closed
    and
    This program has stopped working and needs to be closed
    I don't think the former really exists, either.
    Clearly you don't use Microsoft office products at all regularly. If you were, a dialog box showing the first message would be a familiar, if intermittent, part of the windows shutdown procedure.

  2. #17
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    Can't remember the exact messages >_<
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #18
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    I still hold the opinion that continuing to execute in any way at all, after program state has been corrupted, is dangerous. Especially if your crash handler does something like writing to a file.

    If the world is whacked, who knows what might happen. It's like being on a psychedelic trip. You might think you're smelling roses when in fact you're stabbing someone in the chest.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  4. #19
    Professional Chef leeor_net's Avatar
    Join Date
    Apr 2004
    Location
    Charles Town, WV
    Posts
    147
    Quote Originally Posted by Angus View Post
    Am I the only one who thinks that the "This program has stopped responding and needs to be closed" is not a seg fault, but a freeze, caused by an infinite loop or some such thing?
    No, you're not. The thing is that message does not always mean an infinite loop. That same message is displayed whenever a program (on Windows specifically) derails be it access violations, infinite loops, divisions by zero and so on. It is a generic message displayed by Windows which, unfortunately, gives users very little information about what the problem may be. *nix based platforms at least dump some sort of error (hence the term segfault).

    Quote Originally Posted by brewbuck View Post
    I still hold the opinion that continuing to execute in any way at all, after program state has been corrupted, is dangerous. Especially if your crash handler does something like writing to a file.
    You're right. Which is why in the method I'm using the program doesn't continue to do anything. As soon as it crashes, that's it. The program is done. Instead, a separate program in a separate process which is monitoring the crashing program is what does the error reporting. At least that's how it works on the Win32 end. It does, however, switch to an error handler in the Mac build (not a mac programmer so I don't know if the error handler program I'm using could be ported to do something similar.)
    - Leeor

  5. #20
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,454
    Quote Originally Posted by leeor_net View Post
    No, you're not. The thing is that message does not always mean an infinite loop. That same message is displayed whenever a program (on Windows specifically) derails be it access violations, infinite loops, divisions by zero and so on.
    It even could be shown when the program is working perfectly fine, just using 100% CPU for some high-load task and fails to respond in timely manner to the messages sent by OS
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  6. #21
    Professional Chef leeor_net's Avatar
    Join Date
    Apr 2004
    Location
    Charles Town, WV
    Posts
    147
    That too -- single-threaded apps tend to do this if they're CPU intensive (programs like BSP compilers, for example).
    - Leeor

  7. #22
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by leeor_net View Post
    You're right. Which is why in the method I'm using the program doesn't continue to do anything. As soon as it crashes, that's it. The program is done. Instead, a separate program in a separate process which is monitoring the crashing program is what does the error reporting. At least that's how it works on the Win32 end. It does, however, switch to an error handler in the Mac build (not a mac programmer so I don't know if the error handler program I'm using could be ported to do something similar.)
    So some other program catches the crash and scans out the backtrace from the dying process? Cool. On Mac, you could probably do something similar by forking your main process from a crash handler which ptrace()'s it. Since ptrace() intercepts all signal delivery, this is going to slow your process down whenever it receives a signal, but assuming it doesn't get signals very often it could be an acceptable method.

    EDIT: Actually on Mac, maybe you'd use ktrace instead. I'm not an expert either.
    Last edited by brewbuck; 03-14-2009 at 01:47 AM.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  8. #23
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by vart View Post
    It even could be shown when the program is working perfectly fine, just using 100% CPU for some high-load task and fails to respond in timely manner to the messages sent by OS
    One might argue that failing to respond to messages in a timely manner is a fault in itself. For an event-driven app, that could be considered unacceptable.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #24
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,454
    Quote Originally Posted by brewbuck View Post
    One might argue that failing to respond to messages in a timely manner is a fault in itself. For an event-driven app, that could be considered unacceptable.
    if you see a sign that limits speed to 60 and continue to drive on 160, you may fail to make a proper curve... I do not think this is a failure of the vehicle...
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  10. #25
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    That metaphor completely fails to make me see your point.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #26
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,454
    Quote Originally Posted by CornedBee View Post
    That metaphor completely fails to make me see your point.
    each program has known limitations to its usage... if your overload it and due this incorrect usage program stops responding in timely manner... I do not see it as a bug of the program, maybe of the design that implies the limitation, but not the program itself.
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  12. #27
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    That's nonsense. No matter how much a GUI program does, it should always prioritize (and thus handle in a timely manner) user interaction. Even if it is only to say, "Go away, I'm busy."
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #28
    Professional Chef leeor_net's Avatar
    Join Date
    Apr 2004
    Location
    Charles Town, WV
    Posts
    147
    Quote Originally Posted by brewbuck
    One might argue that failing to respond to messages in a timely manner is a fault in itself. For an event-driven app, that could be considered unacceptable.
    I would argue that for an event driven app this should be considered unacceptable.

    Quote Originally Posted by CornedBee
    That's nonsense. No matter how much a GUI program does, it should always prioritize (and thus handle in a timely manner) user interaction. Even if it is only to say, "Go away, I'm busy."
    Agreed. The so called 'error' may not be that of the vehicle but definitely of the driver. In this case, a program that is not responding due to being 'busy' is unaccetable behavior in any event-driven operating system (e.g., all modern OS's). Failing to respond is considered a badly behaved operating system and, in the good old days of Windows '95 (cringe), that sort of an application would often have the effect of bringing the entire OS to its knees which would force the user to restart their computer. It's one reason why programs are allowed to create separate threads -- throw the cpu heavy stuff in the one thread and respond to the OS with the main thread.

    Thankfully modern OS's handle misbehaving applications in a better way (they tell you that the app is misbehaving and are prepared to kill it).
    Last edited by leeor_net; 03-16-2009 at 05:55 PM.
    - Leeor

  14. #29
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,288
    Quote Originally Posted by CornedBee View Post
    That's nonsense. No matter how much a GUI program does, it should always prioritize (and thus handle in a timely manner) user interaction. Even if it is only to say, "Go away, I'm busy."
    That's what setting the cursor to the wait cursor (the hourglass) is for.

    Very commonly for apps that otherwise respond just fine, someone somewhere will provide it more data than it can process in an acceptable amount of time, and cause it to become "not responding". I have a feeling that putting up the wait cursor stops that, but I could be wrong.
    It's not always easy or even practical to process user input while you're busy.
    Of course we should all try hard to keep our app responsive, for our users sake.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  15. #30
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by iMalc View Post
    That's what setting the cursor to the wait cursor (the hourglass) is for.

    Very commonly for apps that otherwise respond just fine, someone somewhere will provide it more data than it can process in an acceptable amount of time, and cause it to become "not responding". I have a feeling that putting up the wait cursor stops that, but I could be wrong.
    It's not always easy or even practical to process user input while you're busy.
    Of course we should all try hard to keep our app responsive, for our users sake.
    It doesn't have to respond to everything I want, but it should at least allow me to exit, if I've accidentally started an operation that is going to take six hours to finish. Having an app go to la-la land with the only way to kill it being the task manager is just junk coding. Forcibly killing the app could corrupt data.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Page 2 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Ban pointers or references on classes?
    By Elysia in forum C++ Programming
    Replies: 89
    Last Post: 10-30-2007, 03:20 AM
  2. sorting with pointer of pointers to array
    By dunpealslyr in forum C++ Programming
    Replies: 6
    Last Post: 10-01-2007, 11:26 PM
  3. Question About Pointer To Pointer
    By BlitzPackage in forum C++ Programming
    Replies: 2
    Last Post: 09-19-2005, 10:19 PM
  4. Compiler "Warnings"
    By Jeremy G in forum A Brief History of Cprogramming.com
    Replies: 24
    Last Post: 04-24-2005, 01:09 PM
  5. Contest Results - May 27, 2002
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 18
    Last Post: 06-18-2002, 01:27 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21