Process of my program wont end sometimes

[onkelhotte]

Hi there,

when I close my QuickWin program, the process wont terminate sometimes. When it ran in debug mode, CPU utilization jumps from 50% to 100% (dual core system) and after a while a breakpoint is triggered. But there is of course no source code available, only disassembly. Output from debug shows the following:

First-chance exception at 0x7c918fea in ofen.exe: 0xC0000005: Access violation writing location 0x00000010.
First-chance exception at 0x005f02c3 in ofen.exe: 0xC0000005: Access violation writing location 0x0062edbd.
First-chance exception at 0x005f02c3 in ofen.exe: 0xC0000005: Access violation writing location 0x0062edbd.
(this line comes very very often)
First-chance exception at 0x005f02c3 in ofen.exe: 0xC0000005: Access violation writing location 0x0062edbd.
First-chance exception at 0x7c918fea in ofen.exe: 0xC0000005: Access violation writing location 0xfeeefefe.
First-chance exception at 0x0069bc3c in ofen.exe: 0xC0000091: Floating-point overflow.
First-chance exception at 0x005f02c3 in ofen.exe: 0xC0000005: Access violation writing location 0x0062edbd.
First-chance exception at 0x005f02c3 in ofen.exe: 0xC0000005: Access violation writing location 0x0062edbd.
First-chance exception at 0x005f02c3 in ofen.exe: 0xC0000005: Access violation writing location 0x0062edbd.
First-chance exception at 0x005f02c3 in ofen.exe: 0xC0000005: Access violation writing location 0x0062edbd.
ofen.exe has triggered a breakpoint

The disassembly shows the following:

005C2471 call _for__exit_handler (5F1D80h)
005C2476 mov eax,dword ptr [_for__l_excpt_info (733028h)]
005C247B test eax,eax
005C247D je _for__issue_diagnostic+370h (5C2490h)
005C247F push eax
005C2480 call _for__free_vm (5C470Ch)
005C2485 pop ecx
005C2486 mov dword ptr [_for__l_excpt_info (733028h)],0
005C2490 test esi,esi
005C2492 je _for__issue_diagnostic+375h (5C2495h)
005C2494 int 3
(at that line the debugger stops)

In Release mode, the process stays in memory, allocating more and more memory.

Im using WinXP Pro SP2, IVF 10.1.025.
Compiler options for debug:
/nologo /Zi /Od /GB /gen-interfaces /warn:declarations /warn:unused /warn:truncated_source /warn:interfaces /Qsave /Qfpstkchk /iface:cvf
/module:"Debug/" /object:"Debug/" /traceback /check:pointer /check:bounds /check:uninit /libs:qwin /c
/libs:static /Qprec-div-

Compiler options for Release:
/nologo /O3 /Og /G6 /QaxK /QxK /Qparallel /warn:none /Qsave /iface:cvf /module:"Release/"
/object:"Release/" /libs:qwin /c /libs:static /Qprec-div-

Thanks in advance,
Markus

[Steven_L_Intel1]

I'd wonder if something earlier in the program corrupted memory. Thsi can be difficult to track down. I usually approach problems like this by commenting out chunks of code towards the "end" of the program until the problem goes away, then I focus on the last chunk disabled. This may be difficult for an interactive program.

[onkelhotte]

Quoting - Steve Lionel (Intel)

I'd wonder if something earlier in the program corrupted memory. Thsi can be difficult to track down. I usually approach problems like this by commenting out chunks of code towards the "end" of the program until the problem goes away, then I focus on the last chunk disabled. This may be difficult for an interactive program.

I already enabled Generate Block Interfaces and Check Routine Interfaces to find some memorycorruptions. Last week or the week before I had another problem when endingmy program:

On my main dialog I have a tab control. In one of the child dialogs I read out a file. The contents are written into a combo box. When ending the program, it stoped with a file accessing error, always at different positions of the file. That hints to memory problems too.

I try to disable a few chunks and see what happens...

Markus

PS: My program just crashed while it was running with the same error message. Access violation writing location and after printing that a thousand times a Floating-point overflow comes up, followod by Triggered a breakpoint

[jimdempseyatthecove · Accepted solution]

Quoting - onkelhotte

I already enabled Generate Block Interfaces and Check Routine Interfaces to find some memorycorruptions. Last week or the week before I had another problem when endingmy program:

On my main dialog I have a tab control. In one of the child dialogs I read out a file. The contents are written into a combo box. When ending the program, it stoped with a file accessing error, always at different positions of the file. That hints to memory problems too.

I try to disable a few chunks and see what happens...

Markus

PS: My program just crashed while it was running with the same error message. Access violation writing location and after printing that a thousand times a Floating-point overflow comes up, followod by Triggered a breakpoint

Markus,

Check for a programming error along the line of:

Thread A initializes buffers for your application (new or allocate) and spawns thread B
Thread B uses buffers allocated by thread A (reading file for combo box).
Upon signal or event to end program thread A deletes buffer while thread B performing I/O into buffer.

In the above scenario you will need to insert a test to assure thread B has exited prior to starting your cleanup (deletes).

Jim Dempsey

[jimdempseyatthecove]

When you see a memory access error near location 0 (0x00000010 in your above case), this typically occures while accessing memory via a NULL pointer. e.g. pointer points to a structure and you are referencing 0x10 off of this pointer.

If you can debug trap on the access, you can at timeslook at the code to see which section of code (by looking at the call stack) and this may lead you to the section in your code and help you to identify the sounce of the problem. (e.g. your thread B performing I/O into a buffer that was deleted).

Jim Dempsey

[onkelhotte]

You were right Jim. When ending the program, my callback routines performed I/O operations and several DlgSet/Get actions. But internally all the resources were deleted I think.

Now I test the callcacktype and after terminating the program over 20 times the program closes without any error!

What a dumb programming error :-)

Markus