0

I have several core dump files created by manually killing a memory leaking process. I'm trying to open it with GDB, however gdb reports that (no debuggung symbols found). From what I understand, that means that the program was compiled without -g option, which is correct, and because of that, GDB has nothing to catch.
I however, want to only open the core dump file, I need to read it in order to find some sort of memory leak. I can try to recompile program with -g flag, however following executable will no longer be the same as the one that produced the core dump file.
When I try to do a backtrace, I get this 

#0  0x0000003c992325e5 in ?? () from /lib64/libc.so.6
#1  0x0000003c99233dc5 in abort () from /lib64/libc.so.6
#2  0x00007f961117d3f2 in PrepareDumpAreas () from /opt/mqm/lib64/libmqe_r.so
#3  0x0000000000000000 in ?? ()

that tells me, that he is for some reason unable to read the executable I provided, but thats impossible because I'm sure the exe is correct. Might this be another result of the fact that it was not compiled for debugging?
My Question is: Is there another way to read dump core files? What can I do to make GDB work the way I need.
EDIT1: I also ran my own set of tests and watched, if the memory requirements for the process increased. On my enviroment, no leak was apparent. So it is specific for enviroment of my client (and, perhaps, specific to message loads that my program has to carry out)

Lone_Wanderer
  • 179
  • 1
  • 3
  • 16
  • 1
    Your task seems impossible, finding memory leaks from a core dump without symbols. Why not insert test/debug statements in the pogram? – Paul Ogilvie Feb 02 '17 at 12:13
  • I thought about that. Problem is, that program ran for some time on environment of our client. He noticed memory leaks and he sent the core dump. I could put those debug statements into the code, however we would have to send the recompiled program back to the client and wait for weeks before we could get another core dump. I also cannot simulate such large environment to simulate it myself.. – Lone_Wanderer Feb 02 '17 at 12:19
  • @PaulOgilvie Finding leaks using a core dump *with* symbols is also going to be just about impossible. For every block of memory found in the heap, find out if it's referenced *anywhere*, and determine the validity of those references? *Then* determine if those will leak? Then if a reference can't be found for an active block, determine where it came from? – Andrew Henle Feb 02 '17 at 12:20
  • 2
    @Lone_Wanderer *I also cannot simulate such large environment to simulate it myself.* So, your company is not completely testing its product? How much is it going to cost your company to pay you to run down these leaks? How much would it cost to build a proper testing environment - where you can run your product under something like Valgrind or Purify? I bet it's a *lot* cheaper to properly test than it is to go off on Easter Egg hunts for memory leaks. – Andrew Henle Feb 02 '17 at 12:23
  • 3
    Is valgrind an option for you? http://valgrind.org/ – robin.koch Feb 02 '17 at 12:24
  • @AndrewHenle Our product was working fine for quite some time. The problem occured after time, when versions and software solutions changed in client's environment. The reasons on why there is not complete testing enviromnet are not important. As of now, I needed to find a way (if there is one and it is feasible) to read core dump and to find out if there is a way to figure out a location of a memory leak from it. – Lone_Wanderer Feb 02 '17 at 12:33
  • @robin.koch Such sollution is not feasible due to the fact that our program runs in pre-prod/production environment. Because of nature of the data, client is not quite keen on deploying analyzing software onto his servers. It is option for my company's enviroment, and I will try to install it on ,,my" servers, thank you for suggestion. – Lone_Wanderer Feb 02 '17 at 12:35
  • @Lone_Wanderer *Our product was working fine for quite some time.* No, you *believed* it was "working fine". Absence of evidence is not evidence of absence. How many hours at how many $/hour are you going to burn on this Easter Egg hunt you seem determined to go on? *The reasons on why there is not complete testing enviromnet are not important.* Does your boss know how **expensive** for your company those "not important" reasons have now become? You don't find memory leaks from core dumps - you find them with analytic run-time tools like Valgrind when you run in a proper test environment. – Andrew Henle Feb 02 '17 at 13:07
  • 1
    How did your client "notice memory leaks"? Where does the core dump come from? Still seems setting up a test environment, al be it only to (exhaustively) test the memory management, seems the best way forward. – Paul Ogilvie Feb 02 '17 at 13:48

0 Answers0