- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hi fellow CheckMates,
I am currently having a issue, a very strange one, with fw ctl zdebug, more accurately, when I issue "fw ctl zdebug drop" I get the following error.
kiss_kdebug_command: memory allocation failed, aborting.
Defaulting all kernel debugging options
Debug state was reset to default.
Does anyone ever saw this? If yes, how did you resolve it?
This is a VSX R80.30, and occurs in all member, fresh installed with the latest ISO (take200) and jhf 191.
Thank you and cheers
BR
Hi CheckMates,
The root cause of the issue is the exhaustion of the kdebug/zdebug address space which is limited to 4GB (this is a 32 bit process).
When using zdebug/kdebug the process will allocate memory in user-space for all the VSs and all the FW instances. The memory grows linearly with each FW instance in the system.
To work around it, use the following command to debug the specific VS.
fw ctl zdebug -v <vsid number> + drop
Please feel free to contact me @cobys@checkpoint.com any questions with this regards.
zdebug is an internal macros that unfortunately leaked out and became way too popular for its purpose.
It is running debug commands with a buffer way too small for the purpose. More info here.
Why don't you run the debug in a proper manner:
fw ctl debug -buf 99999
fw ctl debug -m fw + drop
fw ctl kdebug -f > myfile.txt
when done, run
fw ctl debug 0
Hi @Bruno_Ramos,
"fw ctl zdebug" is a powertool that is not exhausted from being used with "fw ctl zdebug drop". There is not much to be found in Check Point KB or in the documentation. "fw ctl zdebug" is an R&D tool for testing software in development. Therefore, the insert should be used with care. It starts a debugging in the background until it is aborted with CTRL+C. On productive systems it can have a high performance impact. Furthermore, the debug buffer is not the largest.
What happens when you execute! It is a macro that executes the following commands:
fw ctl debug -buf 1024 <<< The debug buffer is preset to 1024.
fw ctl debug [The option behind "fw ctl zdebug"]
fw ctl kdebug -f
[Wait until CTRL+C is pressed]
fw ctl debug 0
More read in this article:
"fw ctl zdebug" Helpful Command Combinations
Same here.
Works on 21800 Gaia R80.30 R155 VSX, fails with identical message on 23800 Gogo R80.30 T155 VSX.
Also, using fw ctl debug instead of zdebug does not solve it:
# vsenv 3
Context is set to Virtual Device ******* (ID 3).
# fw ctl debug -buf 99999
Initialized kernel debugging buffer to size 8192K
# fw ctl debug -m fw + drop
Updated kernel's debug variable for module fw
Debug flags updated.
# fw ctl kdebug -f > myfile.txt
# fw ctl debug 0
Defaulting all kernel debugging options
Debug state was reset to default.
# tail myfile.txt
Module: cluster
Enabled Kernel debugging options: None
-----------------------------------------------------
HOST:
Module: IDAPI
Enabled Kernel debugging options: None
-----------------------------------------------------
kiss_kdebug_command: memory allocation failed, aborting.
Problem with Gogo?
If you cannot start kernel debug with the maximum debug buffer, please open a support call with TAC
Got it. Checking with R&D in parallel.
Hi all,
Thank you for all the replies.
I tried JHF 155 and 195 and the issue persist.
I have a SR open with TAC and R&D, as soon as i can I will update you all.
Thanks
BR
Hi CheckMates,
The root cause of the issue is the exhaustion of the kdebug/zdebug address space which is limited to 4GB (this is a 32 bit process).
When using zdebug/kdebug the process will allocate memory in user-space for all the VSs and all the FW instances. The memory grows linearly with each FW instance in the system.
To work around it, use the following command to debug the specific VS.
fw ctl zdebug -v <vsid number> + drop
Please feel free to contact me @cobys@checkpoint.com any questions with this regards.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 25 | |
| 23 | |
| 17 | |
| 12 | |
| 10 | |
| 6 | |
| 6 | |
| 5 | |
| 5 | |
| 5 |
Tue 11 Nov 2025 @ 10:00 AM (CET)
Your First Response: Immediate Actions for Cyber Incident Containment- EMEATue 11 Nov 2025 @ 06:00 PM (COT)
San Pedro Sula: Risk Management al Horno: ERM, TEM & Pizza NightTue 11 Nov 2025 @ 06:00 PM (COT)
San Pedro Sula: Risk Management al Horno: ERM, TEM & Pizza NightTue 11 Nov 2025 @ 10:00 AM (CET)
Your First Response: Immediate Actions for Cyber Incident Containment- EMEAThu 13 Nov 2025 @ 10:00 AM (CET)
Cloud Architect Series - Guarding Generative AI: Next-Gen Application Security with CloudGuard WAFFri 14 Nov 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Veriti, Threat Exposure ManagementWed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsTue 11 Nov 2025 @ 06:00 PM (COT)
San Pedro Sula: Risk Management al Horno: ERM, TEM & Pizza NightTue 11 Nov 2025 @ 06:00 PM (COT)
San Pedro Sula: Risk Management al Horno: ERM, TEM & Pizza NightAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY