i am using AIX OS.here i am facing a problem that when ever the process crashes there is no stack written in the log.it just gives an information of signal11/10/4 has occured.
but no stack is shown.
since the code is an optimized code i am even not able to debud using dbx.gdb is not installed.
could you please suggest how to see the stack trace whenever the program crashes.
might be with any other tool or incase any cheet method to follow to view the actual stack trace?
advance thanks for the help.
This works on AIX 5.1:
Use the ulimit command to set the limit for core dumps, before you start the binary (the limit is likely set to 0, which means you're not getting any core dump at all). You will need to do this in the same shell as the process you run. Then you can use the debugger to see the stack in the core. You will need to have debugging symbols in the binary to make much sense out of it, though. Check 'man ulimit' to see how ulimit works. Good luck!
Related
I've created a C-Watchface on Cloudpebble (which works fine). I'm refactoring it to make the code cleaner.
But I'm getting this Error after the Installation:
[FEHLER] ault_handling.c:78: App fault! {1030da8e-9563-4db9-a08f-b8d6d274e8dd} PC: 0x805ea85 LR: ???
Is there a way to get a Human Readable Error Message? Do I have to use the SDK for that?
Debugging on Pebble is not an easy task sometimes.
What you're experiencing is PebbleOS telling you that the crash was your app's fault, and that the OS has been a good little boy.
Usually what this means is that you are referencing a NULL pointer. I'd recommend using APP_LOG throughout parts of your code to check your pointers and make sure you are not destroying anything if you're still using it.
If you are able to break away from the wool sweater of CloudPebble, which keeps you warm but is always a bit itchy, you can use gdb to set breakpoints and do much more thorough debugging.
Read more here on common runtime errors, or read more here for gdb.
My application is crashing sometimes while running on real device but the debugger always goes to "main.m" class not where the app is exactly crashing.
Infect console log is also not telling anything about the crash.
I think there is some settings required for debugger but not exactly know the right solution for that. Please help.
Check your device logs for an app type of Unknown. Often, an app will crash by being killed by the OS and an unknown log entry will appear on your device logs showing that your app is the largest memory consumer. To figure out which piece of code is causing the crash, evaluate the UI behavior and add a breakpoint at the appropriate spot (probably where you start working with your data).
Perphaps this could be a memory issue. In that case debugger does not show warning or exceptions. you can use instruments like profile provided in xcode to backtrace the issue. You can also backtrace your issue in Report navigator in xcode.
You can also use apps like crashlytics. Upload your build to crashlytics and then download it from theer and use it. Once it gets crashed .Login on web and check for the crashes. It will show the exact line where got gets crashed.
I hope it can help you.
I'm trying to debug for the first time a gtk code and actually, I want to debug a callback function for key-press-event so I set a breakpoint with gdb and when it hits the breakpoint, the whole desktop evirement is freezing (I'm running under gnome-shell) it seems that the graphic envirement is waiting for the event to finish.
I got some idea that didn't worked :
The first attempts was to assign some gdb commands to the breakpoint :
(gdb) break on_key_press_callback
(gdb) commands
> back trace
> next
> next
> next
> continue
> end
but I don't know why, only the back trace command is executed, and then freeze.
The second attempt was to debug remotely using gdbserver and gdb on tty1 (no graphigs to freeze :) ) I was able to send commands like next and step after the breakpoint but there was nothing to see (can't list code, inspect the stack, ect ...)
So any good tips to be able to debug in such situations ?
Thanks
It's typical to have lockups when debugging an X program running on the same server that you're using to debug. For example, if the inferior (gdb terminology for the program being debugged) does a server grab -- whoops, the gdb GUI (or terminal or emacs etc) is locked out.
Your idea of doing more programmatic debugging is a good one, but it's hard to make it all work nicely. As you found, some gdb commands (basically those related to inferior control) don't work in commands. Also, it just isn't nearly as convenient.
You can go further that direction. For example you could use SystemTap to probe the program instead.
However there are also nicer approaches.
One way is to run the inferior using a virtual X server -- a nested one, or one running in a VM. Then you can escape to the "outer" X server for debugging. This will be much nicer.
Another way is to have two computers, and run the debugger on one and the inferior on the other. In a way this is really the same answer, just using a real machine rather than a virtual one.
The question is old, but for anyone that may be struggling with this issue, there is a way to stop the freezing behaviour from happening by disabling the X server grab.
You have to change the config in your IDE to run the program with the following system property:
-Dsun.awt.disablegrab=true
If you are using javaws (Java Web Start) to run the application use:
-J-Dsun.awt.disablegrab=true
instead.
I searched for a solution to my problem already in Google and here in stack overflow.
I didn't found an understandable and precise solution for my problem:
I've written a program that maintains an inventory.
It compiled without warnings or errors and it works quite well when I type in commands by hand. When I'm running the program with an input file with much more parts I get a segmentation fault 11.
Now I want to debug my program but don't know how to do this using input files.
I already did some debugging via the CodeBlocks IDE. Didn't find a option for this.
I used malloc and realloc functions in my program and think the error happened there because I never used it before.
Could you please help me in following ways:
I need a debugger that can debug while the program runs with an input file.
The debugger must be able to check for memory leaks or things like this.
Thanks
Armin
Debugging with command line input vs. Debugging with a input file is the totally same.
You must understand this.
When you start debugging session in the IDE, it is by default 'no input' mode (no input file).
But you can specify startup conditions for the program, including working directory, command line arguments, etc.
By using these options, you can run the debugging session exactly same as user running the program with input files.
I am using Intel(R) VTune(TM) Amplifier XE 2013 Update 5 (build 274450) for my linux application hotspot collect， but the report says the "[Outside any known module]" consume most of the time, so i want to get more info about the unknow module.
when i read the release notes of the vtune Amplifier, it says "List of hotspots may contain "Outside any known module" on systems with kernel older than 2.6.20 (200233501)", but my linux kernel is "2.6.32", any idea about this?
Check that your program is not generating code on the fly (i.e. is not JIT-ing). You may also want to switch grouping to "Module / Code Location / Call stack" and see which virtual addresses cannot be mapped by VTune to any known module.
I have been suffering from this issue in the past as well and it is very frustrating if you don't know why it is happening.
2 weeks ago I installed Ubuntu 13.04 and vtune update 14 and I was jumping from joy because I could see (again) what happened inside my code.
After doing some updates on my Ubuntu, vtune started to show your problem
I installed the kernel sources.. no help..
I reinstalled the driver, no help.
I reinstalled intel vtune.. no help.
And then I decided to run under root, and what do you know.. It works; no more 'Outside any known module'. I switched back to my regular user, it stopped working. I switched back to my root, and it works. So perhaps some kinds of access issue.
Maybe you could try this.
Probably you have some kernel hidden addresses by kptr_restrict, you ca review the value of "/proc/sys/kernel/kptr_restrict":
kptr_restrict = 0, kernel addresses are provided without limitations (recommended).
kptr_restict = 1, addresses are provided if the current user has a CAP_SYSLOG capability.
kptr_restrict = 2, the kernel addresses are hidden regardless of privileges the current user has.
You can use this option before running the trace:
sysctl -w kernel.kptr_restrict=0
More details here: https://software.intel.com/en-us/vtune-help-enabling-linux-kernel-analysis
Hope this helps!