Is there a way to disable GDB log files from cortex debug?

[basprins]

Hi, I am using cortex debug in docker. Unfortunately I have some issues (reported here before, but not related to cortex-debug), which might find their root cause in either the GDB server of the arm toolchain I am using, or, caused by JLink. Anyway, the problem results in that the debug sessions breaks, and GDB starts to produce insane amounts of logging (repeatedly trying to read registers, which result in errors, which result in massive log files.

I just cleaned up about 600 GB on log files produced by GDB, just a short list of many many files produced over time:

386257596 ./b2e7fd0d6b38f06a9bbfe6b7c30cced70df6efc92bb32ff5d97c0679fac96e15/merged/tmp/gdb-server-console-312272.log 386257596 ./b2e7fd0d6b38f06a9bbfe6b7c30cced70df6efc92bb32ff5d97c0679fac96e15/diff/tmp/gdb-server-console-312272.log 209543956 ./b2e7fd0d6b38f06a9bbfe6b7c30cced70df6efc92bb32ff5d97c0679fac96e15/merged/tmp/gdb-server-console-495710.log

Would there be any chance I can disable GDB logging through cortex debug?

[haneefdm]

They should not be getting that big. I will look into it.

Meanwhile, use the "cortex-debug.dbgServerLogfile": "/dev/null" setting to send it to a dummy/invalid file.

Btw, you did not use a proper method of submitting an issue. So, I can't tell what OS you are using.

[haneefdm]

I apologize for this. However it happened, I did not anticipate it growing to such huge sizes. Not sure if this is specific to docker though.

To create such huge logs, you must use our extension a lot. Thanks.

[basprins]

Apologies for not filling in the template. I am running on ubuntu 23.04.

This works fine. When I need to enable logging I will remove the configuration item.

I think it makes sense to cap the log files to a certain file. Maybe a few more words on what happens here:

• launch debugger on target
• it occurs (unfortunately for us) on daily basis that (we suspect) JLink runs into an error and looses control over the CPU
• Since the debug session is still running, GDB goes into a loop trying to read registers from CPU
• This fails, and it seems to retry without any delay
• The log file gets appended with "unable to read R[a,b,c,d,etc]"
• If I am not behind my desk at that moment, and leave this running for 5 minutes, you can imagine the insane amount of logging produced in one file.

This problem occurs more frequently when I switch on the "FreeRTOS" option in cortex-debug, if you can remember the issue I reported a month or so ago. You already explained that cortex-debug does not handle this option in any way, but simply passes it through to JLink in my case. But since this triggers the problem really often, I am suspecting the root cause is in JLink.

I have read enough issues on JLink support website to know better than reporting the issue. Pretty much all of them end with a statement from SEGGER employees claiming "that's not our problem, go away" ;-).

So, long story short: the problem is not in cortex debug, but to be able to control not producing log files would be a great solution in my case.

"cortex-debug.dbgServerLogfile": "/dev/null" seems to work, just tested it. Although cortex-debug doesn't seem to recognize it as a valid option:

But, no more log files so far so I think I am good

root@legion:/home/bp/docker/overlay2# find . -iname gdb-server-console* -delete
root@legion:/home/bp/docker/overlay2# find . -iname gdb-server-console*
root@legion:/home/bp/docker/overlay2# find . -iname gdb-server-console*
root@legion:/home/bp/docker/overlay2# find . -iname gdb-server-console*
root@legion:/home/bp/docker/overlay2# 

[haneefdm]

"cortex-debug.dbgServerLogfile": "/dev/null" seems to work, just tested it. Although cortex-debug doesn't seem to recognize it as a valid option:

It is a setting (user or workspace or folder). Not something that goes into launch.json. It worked because we combine the settings with what is in launch.json

If you are in a shell, you should probably escape the *

find . -iname gdb-server-console\*

[basprins]

ah, right. apparently the log files weren't produced yet. Not sure when that happens, i assumed as soon as I launched in the debugger. But after your message I checked again and there indeed were log files produced.

Moved the line as you suggested to settings.json

root@legion:/home/bp/docker/overlay2# find . -iname gdb-server-console*
./b2e7fd0d6b38f06a9bbfe6b7c30cced70df6efc92bb32ff5d97c0679fac96e15/merged/tmp/gdb-server-console-60066.log
./b2e7fd0d6b38f06a9bbfe6b7c30cced70df6efc92bb32ff5d97c0679fac96e15/merged/tmp/gdb-server-console-58705.log
./b2e7fd0d6b38f06a9bbfe6b7c30cced70df6efc92bb32ff5d97c0679fac96e15/diff/tmp/gdb-server-console-60066.log
./b2e7fd0d6b38f06a9bbfe6b7c30cced70df6efc92bb32ff5d97c0679fac96e15/diff/tmp/gdb-server-console-58705.log
root@legion:/home/bp/docker/overlay2# find . -iname gdb-server-console* -delete
root@legion:/home/bp/docker/overlay2# find . -iname gdb-server-console*
root@legion:/home/bp/docker/overlay2# find . -iname gdb-server-console*

Seems to work better now. Thx a lot for the quick support again!!