tags:

views:

267

answers:

4

I have a large C++ function which uses OpenCV library and running on Windows with cygwin g++ compiler. At the end it gives Aborted(core dumped) but the function runs completely before that. I have also tried to put the print statement in the end of the function. That also gets printed. So I think there is no logical bug in code which will generate the fault.

Please explain.

I am also using assert statements.But the aborted error is not due to assert statement. It does not say that assertion failed. It comes at end only without any message.

Also the file is a part of a large project so I cannot post the code also.

gdb results:

Program received signal SIGABRT, Aborted.
0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
A: 

You don't give us much to go on. However, this looks like you are running into some problem when freeing resources. Maybe a heap corruption. Have you tried running it under gdb and then looking where it crashes? Also, check if all your new/delete calls match.

Michael Ulm
I am not doing any dynamic memory allocation. I have updated the gdb results.
avd
You can use the `bt` command in gdb to get the stack back-trace when the programm crashes. Maybe the original calling function is to see there. Also it helps if the application is compiled with gcc's -g switch.
Rudi
A: 

Load the core dump together with the binary into gdb to get an idea at which location the problem list. Command line is:

gdb <path to the binary> <path to the core file>

For more details on gdb see GDB: The GNU Project Debugger.

jopa
Where does the core get dumped? I am only getting .stackdump which gdb says that it is not a core file.
avd
Alternatively you can run your program under gdb control.Load it with gdb <path to binary> and enter 'run' when the gdb commandline appears.
jopa
A: 

Run it through AppVerifier and cdb.

E.g.

cdb -xd sov -xd av -xd ch <program> <args>
Alex
+1  A: 

It looks like a memory fault (write to freed memory, double-free, stack overflow,...). When the code can be compiled and run under Linux you can use valgrind to see if there are memory issues. Also you can try to disable parts of the application until the problem disappears, to get a clue where the error happens. But this method can also give false positives, since memory related bugs can cause modules to fail which are not the cause of the error. Also you can run the program in gdb. But also here the position the debugger points to may not be the position where the error happened.

Rudi
+1. I would bet valgrind show some read/write error at some point.
ereOn