I have a Linux script written in C Language deployed at a remote server, to which multiple clients can connect. Due to some reason the script crashed and when I am trying to restart it I am getting segmentation fault.Is there any way by which I can Check at server side that what is stopping my script from starting, and is throwing segmentation fault error.
Start out by enabling core dumps:
$ ulimit -c unlimited
Now run the script until it segfaults. This will create a core dump file in your working directory.
Next, use GDB (or any frontend of it) to debug it (note that you can copy the file to your local machine if you can't debug on the server):
$ gdb -c <core_file>
Don't forget to add the symbol file:
GDB> file my-prog
If it's easy to reproduce the problem, and provided you can debug directly on the server (with SSH or such), you can simply dive in and start the process with a debugger attached:
$ gdb my-prog
Related
I'm not being able to run my C program from the Git-bash terminal on my Windows machine. My code is compiling fine. The problem is just while running it. The command I'm using to compile my code is:
gcc problem1.c
And the command that I'm giving for running the executable is ./a.exe
The error that I'm getting is this:
bash: ./a.exe: Permission Denied
This problem has only recently cropped up. I've been compiling and running programs with git-bash for a long time and never faced this problem. A few days back, I enabled the Windows Subsystem for Linux on my Machine and installed the Ubuntu distribution. I don't know if that has something to do with this. I'm facing the same problem with CMD as well. CMD throws an access denied message when I try to run the code. Thanks in advance.
Try setting first a simplified PATH to reference your Git bash:
set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%PATH%
Then try again executing your compiled exe.
With WSL activiated, some exe might require privilege elevation.
I am trying to debug a cross-compiled application with gdbserver. Unfortunately I get the following error on my host:
Reply contains invalid hex digit 59
Here's what I did:
compiled my application "line-generator" (which is just a test program) with gcc -ggdb3 -std=gnu89 flags (using -g instead of -ggdb3 didn't make any difference)
copy the executable to my embedded system. The exec can be executed there
started gdbserver 192.168.10.20:54320 line-generator on the embedded system
On the host I start gdb: gdb line-generator.gdb
(gdb) target remote 192.168.10.102:54320
Got this response on host:
Remote debugging using 192.168.10.102:54320
Reply contains invalid hex digit 59
On the server I got this:
Remote debugging from host 192.168.10.20
readchar: Got EOF
Remote side has terminated connection. GDBserver will reopen the connection.
Listening on port 54320
I have never used gdb remotely so maybe I am running into a beginner's issue so every response might help.
edit: My gdbserver was provided by the manufacturer of the embedded hardware.
I found out that remote-debugging a cross-compiled executable needs gdb on the host computer to be compiled for this purpuse. In my case it means that I have to use this command
/opt/microblaze-uclinux-tools/bin/microblaze-uclinux-gdb line-g
enerator.gdb
instead of simple gdb line-generator.gdb
Luckily the correct file was provided by the embedded board manufacturer!
To be honest I don't fully understand the context so if someone has an explanation on this I'd be glad to hear this!
cheers, Stefan
So I have this source gdb-1515. I'm using Xcode 3.2.6 command line tools on Snow Leopard (and this gdb source is the source of the gdb included in them).
Trying to run (inside /private/var/root/Downloads/gdb-1515/src/gdb/gdbserver):
gcc -I. -I. -I./../regformats -I./../macosx -I./../../include -I../../bfd -I./../../bfd -I/private/var/root/Downloads/gdb-1515/src/bfd ./../macosx/macosx-nat.c
Fails with:
./../macosx/macosx-nat.c:34:17: error: bfd.h: No such file or directory
./../macosx/macosx-nat.c:35:18: error: defs.h: No such file or directory
./../macosx/macosx-nat.c:36:21: error: gdbcore.h: No such file or directory
./../macosx/macosx-nat.c:37:20: error: serial.h: No such file or directory
./../macosx/macosx-nat.c:38:22: error: ser-base.h: No such file or directory
./../macosx/macosx-nat.c:39:22: error: ser-unix.h: No such file or directory
./../macosx/macosx-nat.c:40:22: error: inferior.h: No such file or directory
./../macosx/macosx-nat.c:41:23: error: objc-lang.h: No such file or directory
./../macosx/macosx-nat.c:42:21: error: infcall.h: No such file or directory
In file included from ./../macosx/macosx-nat-dyld.h:5,
Etc.
Thing is there is no bfd.h anywhere inside the gdb-1515 folder.
find /private/var/root/Downloads/gdb-1515 -name bfd.h
Returns no output.
I want to call attach_to_classic_process (defined inside macosx/macosx-nat.c) from gdbserver/macosx_low.c:476 instead of ptrace - that's why I'm trying to build macosx/macosx-nat.c from the gdbserver directory.
Currently at its place it's used ptrace which fails for rosetta processes.
Ok so I want to debug a classic (Rosetta) process running on Snow Leopard by using remote gdb connection.
It should be obvious cause after all Rosetta applications are using remote connection for debugging anyway.
Additionally gdb application can successfully connect with mentioned PowerPC applications.
I'm trying to compile gdbserver from this apple source however this is Aids - it seems that the way gdbserver included in this packages is fundamentally wrong since the original gdb is using special functions to establish connection to classic process while gdbserver is trying to use ptrace which obviously fails.
Another thing that comes into my mind is why the hell gdbserver has to be so retardedly complicated - why isn't directly co-operating with the functional gdb command line application (maybe a wrapper of sorts)?
I have written a program in C for an embedded device on a Debian-based linux.
One of the devices got a segmentation fault after 8 days running, so it is not a very frequent bug that I can track fast with gdb.
A few years ago I know that I used gdb (with gdbserver, I guess) running the program detached from the shell so I could leave the device running and check every day if something bad had happened, but I don't remember how I did that!
I have tried with gdbserver, connecting to it with gdb, but it stops debugging when I close the connection.
Do you know how to achieve this?
You'll have to detach, not quit gdb like that.
Since you're only in for post-mortems, anyway, I'd however recommend something completely different:
Enable core dumping; as root, run
> sudo -s ##become root
$ echo "* soft core unlimited" >> /etc/security/limits.conf
$ su -l <user that is running the crashing program>
$ ulimit -c unlimited
$ program
##wait for crash
(that lifts any restriction, including the default 0B restriction, on the maximum core dump file size).
Then, after a crash, find the core.* coredump file, and open it with gdb. Voila, the state of the program when crashing is restored in gdb and you can do pretty much anything that you could do with a gdb attached at crash time.
I recently downloaded vim and I made a simple Hello World program in C. I installed clang after I saw that Gcc had errors on cmd. They both did. I also installed cygwin and tried cmd with both compilers and still nothing.
I keep on getting these errors
1 [main] clang 304 child_info_fork::abort: C:\cygwin\bin\cygLLVM-3.5.dll:
Loaded to different address: parent(0x1A10000) != child(0x1710000) clang:
error: unable to execute command: posix_spawn failed: Resource temporarily
unavailable
I think I have more hope for clang than for gcc
Short Answer: If your Cygwin installation is directly under your C: drive, shutdown Cygwin and try this command in the Windows command prompt:
C:\cygwin\bin\dash.exe -c '/usr/bin/rebaseall -v'
This is a Cygwin fork failure.
As noted in link above, one solution is to do a 'rebase':
Read the 'rebase' package README in /usr/share/doc/rebase/, and follow the instructions there to run 'rebaseall'.
According to the README:
Use the following procedure to rebase your entire system:
1. shutdown all Cygwin processes and services
2. start ash or dash (do not use bash or a terminal emulator like rxvt
or mintty). The easiest way to do this is to use Windows Explorer
and navigate to the top level of your cygwin installation, and
double-click ash.exe or dash.exe in the bin/ directory.
3. execute /bin/rebaseall (in the ash/dash window)
If you get any errors due to DLLs being in-use or read-only, then take the
appropriate action and rerun rebaseall. Otherwise, you run the risk of fork()
failing.