Author Topic: unhandled exception in simulator  (Read 3631 times)

Offline alager

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
unhandled exception in simulator
« on: November 26, 2008, 07:53:57 PM »
This happens at random, while the simulator is just sitting there running.  I'm not interacting with it at all.

Code: [Select]
First-chance exception at 0x0046a1d7 in uTaskerV1-3.exe: 0xC0000005: Access violation writing location 0x00000000.
Unhandled exception at 0x0046a1d7 in uTaskerV1-3.exe: 0xC0000005: Access violation writing location 0x00000000.
The program '[2936] uTaskerV1-3.exe: Native' has exited with code 0 (0x0).

Is this normal?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3191
    • View Profile
    • uTasker
Re: unhandled exception in simulator
« Reply #1 on: November 26, 2008, 08:53:17 PM »

This is not desired behavior but it does sometime happen. I expect it is the following (you should be able to see the line by repeating the failed operation):

// Routine to re-enable interrupts on leaving a critical region
void uEnable_Interrupt()                                                 // interrupts are ALWAYS off when entering
#ifdef _WINDOWS
    if (!iInterruptLevel) {
        *(int *)0 = 0;                                                   // basic error - cause simulator exception
    }                                                                    // a routine is enabling interrupt although they are presently off. This may not be a serious error but it is unexpected so best check why...
    if (!(--iInterruptLevel)) {                                          // only when no more interrupt nesting,
#ifndef _WINDOWS

I tend to get such a problem once every day or so since working with Vista (with XP I almost never had it).
If it is annoying, you can in fact remove the 'forced' exception since it is there to warn of misuse of the interrupt enable/disables. However the WinPCap thread is probably injecting Ethernet frames and causing a task switch at an inappropriate moment and so getting the interrupt enable/disables out of sync.

In the last SP I managed to remove one of these possibilities which helped quite a lot, but there must still be a piece of code not being correctly protected (simulator and not target). Unfortunately it happens so infrequently (at least for me) that it is very difficult to debug to find the cause.

As stated above, you can probably stop the exceptions be removing the line of code - it is there to warn of a possible problem so is not that critical. It is also only simulation code checking. I will have a think about how to catch this, hopefully, last problem with this (see also the following for previous work on it you should find this already in the SP that you are using..).