I have a batch script that calls a bunch of programs written in C that do a lot of data processing. It works fine when run manually but when Jenkins calls the batch, one of the programs fails with a useless error message.
Before I litter the program with printf()s, I tried to use DebugBreak() to attach the debugger to see what difference Jenkins is making but the program just ends without invoking the debugger.
Is there a way to invoke the debugger from within the failing program that'll work with Jenkins?
EDIT: I tried calling MessageBox() but nothing appears and Jenkins sits there waiting for console output.
Related
I tried this in VSCode+PHP extension and NetBeans, and both seem to not offer a function like that.
Basically what I want is to keep debugger session for next run but terminate the current PHP execution. I'm debugging a cron job that modifies the DB many times and just don't want the script to complete after I reach a certain point in debugger.
The only function I can see in both IDE's is stop debugging which may or may not abort execution but definitely ends the debugging session.
There's this bug with the placement of certain characters in the embedded terminal in CLion (the Run tab that pops up when you click the Run button), and I figured out that if I changed the terminal in CLion, that wouldn't happen. I changed the terminal to cmder, and it is all working now, except one thing: I can't figure out how to make CLion run the program to that terminal.
I tried changing the configuration, but all it did on run was open cmder but not execute the program (I had to run it manually, by writing the file name).
I wonder, what's the way to fix this, and make CLion directly run C programs on the terminal, instead of the Run tab?
Thank you.
The CLion run configuration always runs in the integreted run window. That is not a terminal emulator, and it cannot be changed so that it runs in an actual terminal emulator (like cmder).
Your best bet is to try to fix the "character placement" in the run window. Maybe ask a different question where you explain the issue, or if it's a clear bug, file a bug report for it.
I had to write code in C and run it for an assignment. Since this is the first time that I'm using C, I downloaded MinGW as a compiler and Code Blocks as an IDE. I had no problem compiling the code given by my professor but it never runs (this is a simulation for an M/M/1 queue). When I say it never runs, I mean that a command prompt like window pops up and nothing happens after that. Every time I close that window and try to compile the SAME program again, I get an error that says that permission to access the file has been denied.
I then deleted Code Blocks and tried running the program through command prompt but I have the same problem. I've now tried doing it using LCC-Win but nothing has changed. Another weird thing that happens when I run any program is that three instances of the .exe file of that particular program are in my processes under task manager. I then need to restart my computer to try compiling that same program.
I even tried running a simple Hello World program and I have the same problem!
I am currently using a Windows 7 32-bit system.
Any help would be greatly appreciated!
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've coded a program in c for an embedded system (Devkit8000, which is a clone of the well known BeagleBoard) running Angstrom Linux.
The program creates a couple of threads, on of them is responsible of taking pictures with a camera connected to the board, and right now the second thread only moves that images to another path. The program should be running during the whole day, and the only way to stop it is sending a signal.
I edited the crontab to launch the program in a specific hour and to send a signal when it has to stop, the issue is that launching the program in this way cause the process to be killed after some time running, but, if i launch the program manually (through the command line), it works perfectly and dont get stopped.
I have no idea about the reason of this different behaviour between crontab and command line. I've checked the system logs but didnt find anything useful. I've also been reading a little and find that the OS can kill a process if it is using so much resources, but doesnt make sense that this happens in only 1 scenario (crontab vs manually)...
Any clue about what is happening?
Thank you in advance!
The main difference is that running a job through cron invokes a non-interactive non-login shell. The effect of that depends on the default shell for your user. For example, if you are using Korn shell or Bash then your .profile will not be executed, as it would on an interactive login shell. Korn shell 88 will execute .kshrc (the $ENV file) but ksh93 will not.
So, a good start might be to call your program from a script, after first "sourcing" your .profile file:
. $HOME/.profile
Failing that... When you say that the process is "killed", do you get such a message? If so, then that sounds like someone sending SIGKILL, i.e. kill -9. If not, then maybe you could run strace or ltrace to find out at what point it dies.