[Bf-committers] Crash Handler

[Alexandr Kuznetsov]

Hi.

I also disabled crash handler on VS.  And indeed, it is not useful for 
not gcc based compiler. Microsoft has own dump format:

MiniDumpWriteDump()


Anyway, it is time to promote Breakpad! 
http://wiki.blender.org/index.php/User:AlexK/Breakpad. It supports most 
compilers and it is system independent, so, for example windows dump can 
be debug on linux. Anyone who wishes to continue this project is more 
than welcomed.
The process can be automated.  This can be beneficial to quickly find 
and fix segfaults.  Mozilla uses special system: 
https://crash-stats.mozilla.com/home/products/Firefox 
https://wiki.mozilla.org/Socorro

Best,
Alex


On 7/22/2013 11:08 AM, Jason Wilkins wrote:
> The problem with changing the settings in Visual Studio's debugger (and
> probably all debuggers) is that I only really care about uncaught
> exceptions.  Some programs/libraries can be very busy with exceptions that
> are caught and handled and then business carries on as usual.
>
> There is a command line switch to turn this off, but since I'm using CMake,
> I have to remember to put the flag each time I rebuild, so I'll probably
> end up commenting out the line that registers the crash handler as a
> workaround until I find a better solution.
>
> What I was suggesting for trunk is to disable the crash handler in Windows
> since it doesn't do anything except close Blender in a non-exceptional way
> (i.e., the OS doesn't know Blender crashed), which is a very unfriendly
> thing to do.  The code for generating a stack dump seems to be disabled.
>   Either that, or make the Windows crash handler more useful.
>
> I'd do something about it myself, but I'm trying not to get distracted from
> GSoC :-)
>
>
>
>
> On Sun, Jul 21, 2013 at 2:33 PM, Doug Gale <doug65536 at gmail.com> wrote:
>
>> In GDB you can use handle SIGSEGV stop.
>> In visual studio, you can go to the Exceptions... dialog and check
>> "thrown" on everything to catch exceptions at the faulting instruction.
>> In CDB/WinDBG/KD you can do sxe av.
>>
>> I think it is a very bad idea to catch segment faults. I was working on
>> blender earlier (in a debugger) and blender just vanished. I didn't know
>> a signal handler had been added to blender.
>>
>> Swallowing the exception and exiting is very bad behavior. For normal
>> users, it is far more confusing for the application to just
>> spontaneously disappear than if it crashed properly. A savvy user could
>> potentially hook up a debugger and get call stacks. In windows, the
>> event log would record the application crash and possibly save a mini-dump.
>>
>> Exiting in a debug build is just an annoyance, requiring the developer
>> to take steps to configure the debugger to stop instead of the blender
>> window disappearing.
>>
>> -Doug
>>
>> On 07/21/2013 03:06 PM, Brecht Van Lommel wrote:
>>> On Mac/Linux you can still use gdb as usual as far as I can tell, the
>>> crash handler doesn't override anything there. Probably something
>>> needs to be fixed on Windows to make blender_crash_handler pass on the
>>> SIGSEGV to the debugger?
>>>
>>> On Sun, Jul 21, 2013 at 10:26 AM, Jason Wilkins
>>> <jason.a.wilkins at gmail.com> wrote:
>>>> I'm probably out of the loop on this, so I apologize if I'm working from
>>>> old information.
>>>>
>>>> I just spent some time scratching my head because my debugger wasn't
>>>> catching segmentation faults (Blender was just disappearing).
>>>>
>>>> Seems that Blender how registers a SIGSEG handler, but this feature
>> seems
>>>> incomplete compared to what a debugger or and operating system provide
>> at
>>>> this time.  I understand that this probably meant to be a user facing
>>>> feature, but at this time, even the "Blender has stopped working" in
>>>> Windows message is more useful than what Blender does now.
>>>>
>>>> Perhaps this feature should be disabled until it is more complete?
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers