Any special requirements in a module to debug?

SPlatten

I've been working on the same project for some time, I have one module I've been debugging fine with breakpoints and watches, however something has happened and now although I can see the output in the "Application Output", my breakpoints are no longer working.

The breakpoint is red, not white with a red outline but solid red. There output I'm seeing only occurs in one place, but the breakpoints are ignored.

Qt Creator:

4.13.1
Based on Qt 5.15.1 (Clang 11.0 (Apple), 64 bit)
Built on Sep 16 2020 01:17:08
From revision 1da2c1f766

JonB

@SPlatten
Can you set a new breakpoint on main() to work? Have you completely emptied out the debug build directory and rebuilt from scratch?

SPlatten

@JonB , have cleaned and rebuilt all, set a break point on the first line of main() and another in the file I'm having problems on the line that outputs to the Application Output.

It stopped on the breakpoint in main(), but didn't stop on the breakpoint in the module I'm having difficulty with.

JonB

@SPlatten
The breakpoint looks like it is active and in the right place. Trouble is, if somehow source code and debug info are out of sync this happens, don't I know.... BTW is this "module" part of current project compilation, not in something else external you're linking with?

Put the breaks all over the offending module, especially in the constructor. Don't 100% rely on one statement being hit. Put in a qDebug() message where the break is to prove to yourself, me & the wider world that the break is definitely being hit.

SPlatten

@JonB , now I feel rather foolish....a rather large penny has just dropped....the file I'm having difficulty with is used not only by the main process but also by a child process it launches and its the child processes output that Im seeing in the Application Output.

kshegunov

@SPlatten said in Any special requirements in a module to debug?:

the file I'm having difficulty with is used not only by the main process but also by a child process it launches and its the child processes output that Im seeing in the Application Output.

There was a way to tell Creator/gdb how to behave when fork()ing, but for the life of me I can't remember where this was set. By default it switches to the child, but it can be made so it stays with the parent, I'm positive.

JonB

@kshegunov said in Any special requirements in a module to debug?:

By default it switches to the child,

? :)
https://sourceware.org/gdb/onlinedocs/gdb/Forks.html

By default, when a program forks, GDB will continue to debug the parent process and the child process will run unimpeded.

If you want to follow the child process instead of the parent process, use the command set follow-fork-mode.

kshegunov

@JonB said in Any special requirements in a module to debug?:

By default, when a program forks, GDB will continue to debug the parent process and the child process will run unimpeded.

If you want to follow the child process instead of the parent process, use the command set follow-fork-mode.

Well, I suppose my frail memory has failed me yet again and I have remembered it exactly in the opposite way of how it is. What can I say ... in any case if the child's is the one supposed to trap the breakpoint, then @SPlatten should use that switch (set where the gdb's additional arguments are supplied - in the debugger configuration pane of Creator).

JonB

@kshegunov
:)
I think @SPlatten was just reporting what he sees in output, not whether the debugger moves to the sub-process or not

its the child processes output that Im seeing in the Application Output

But yours is indeed useful to know, thanks.

kshegunov

@JonB said in Any special requirements in a module to debug?:

I think @SPlatten was just reporting what he sees in output, not whether the debugger moves to the sub-process or not

Let's try my memory again, shall we?
He's getting output from the current attached terminal, which is the parent, joined after a single fork(), the parent after a double fork() or the child with set follow-fork-mode after a double fork(). Be sure to shoot me down if I'm mistaken. :)

JonB

@kshegunov
He's OK. You need the spoon() method :)

Actually, I see what you mean, maybe he did want to switch to debugging the child process. But when the fork() then exec()s, will the gdb follow that (to the new process) just because of fork mode?

kshegunov

@JonB said in Any special requirements in a module to debug?:

But when the fork() then exec()s, will the gdb follow that (to the new process) just because of fork mode?

If I understand the question correctly, yes.

JonB

@kshegunov

If you have set detach-on-fork to on, GDB will debug both the parent and the child process.

Put that on your fork and eat it! ;)

Also I found

If you ask to debug a child process and a vfork is followed by an exec, GDB executes the new target up to the first breakpoint in the new target. If you have a breakpoint set on main in your original program, the breakpoint will also be set on the child process’s main.

Nice one :)

kshegunov

@JonB said in Any special requirements in a module to debug?:

GDB will debug both the parent and the child process.

This is going to be just very confusing, if you ask me ... I'd rather keep only one victim on a fork.