Locate Class/Method from Dll hex address

[sivrisinek]

Hello there,

i am having a problem which i could not locate for weeks please help..

We have an application which loads some hundreds of components from some 30 dlls (dlls of our own, dlls from qt and others).

We have a system which does the same processing in a production line, which should also do many additional logging, visualisation etc work. So many things run time critical. Furthermore, for historical reasons, many parts of the software are in race conditions. :(

Therefore the realtime behaviour is most of the time different in debug mode.

I have:

- i have tried to regenerate the problem with the debug build, but it does not appear in debug mode..

- checked all possible locations for NULL Pointers, put if statements which will not execute the in case of NULL pointer..

- put some asserts which can give a clue about a value error, did not bring anything..

Now only information i have is from the windows system log, which tells this:

"Crashed application myapplication.exe, version 1.2.3.4,
crashed module qtgui4.dll, version 4.2.2.0,
error address 0x00320275"

Is there any method to locate the method/class which corresponds to that hex address?

If this is because of some privacy issue not possible can someone at least TELL which method that is without giving a method to retrieve this information? It would also help.

Thanks in advance

[wysota]

This address is in code section of the application and will depend on the different relocations of different libraries. What you can do is run the application under debugger, stop it, set a breakpoint to this address, continue and read the stack frame when the breakpoint is reached. But I can't guarantee it will work at all :)

[sivrisinek]

This address is in code section of the application and will depend on the different relocations of different libraries.

If you mean the way the solution is structured, it was not changing since long. if you mean at each new linking it might get differently linked, i can not know if we have some huge changes which might cause this.. anyway i want to find an address in a Qt Dll and i do not relink Qt Dll anyway :)



What you can do is run the application under debugger, stop it, set a breakpoint to this address, continue and read the stack frame when the breakpoint is reached.

Do you mean that the addresses for debug and release dlls are the same? I do not know these issues i'am just trying to understand. If the debug dll has no shift in addresses as compared to the release dll (i would say because of some debug labels it might be different) it should work.



But I can't guarantee it will work at all :)

Thanks a lot any help is appreciated, if it will not help, at least it will give some insight.

[wysota]

If you mean the way the solution is structured, it was not changing since long.
I mean the way the dynamic linker links parts of the executable together during application startup.

anyway i want to find an address in a Qt Dll and i do not relink Qt Dll anyway :)
Finding an address in Qt DLL won't do you any good. You need to find address in your code that called the method from Qt's library that was the direct cause of the crash. What will you gain from knowing the crash occured at destructor of QString?

[quote]Do you mean that the addresses for debug and release dlls are the same?
I mean you need to run the exact same executable that caused a crash and make it stop before it crashes. Or just make it crash under debugger. The effect will be the same (or even better).

[sivrisinek]

I can not regenerate the same crash in debug build this IS the reason why want to find the problem using the release build.

The crash is happening sporadically. We can not attach its reason to something specific.

That's why i am longing for -yes- even the simplest clue like QString destructor, it IS better than what i have now: "nothing". :confused:

[wysota]

I didn't say you were to use debug build. You were to use the very same executable that crashed.

Believe me, destructor of QString would tell you exactly nothing, especially if your system is threaded.