0

in a very specific C++ environment (an application to analyse CAD-drawings), dbg becomes extremely slow when I try to import large drawings....

In this test environment I integrated GoogleTest/GoogleMock testing framework to manage the test results and extract relevant (debug) data, and do the JNI mocking to be able to test without the Java EE "counterpart" of the application.

For 1 specific drawing the processing is grossly delayed, in another case the dbg application itself seems to be "frozen" indefinitely. It reacts on no signal whatsoever anymore: if you press the "termination" button in the toolbar of the debug console (the "red square"), the message: "Termination Failed" appears. I eventually shut it down by terminating the debug thread.

When I run this "drawing import" WITHOUT debug (so just "run"), all is processed in about 15-20 seconds (and no catatonic behaviour of the environment). In this configuration, the application runs on Linux (within a VirtualBox within a Windows environment) .... Question: what could be the case here? I tried to extract some relevant info but dbg gives nothing away. Any bright idea's?

Thank you in advance.

SoHerman
  • 71
  • 1
  • 1
  • 7
  • Double check you have not left a "break on value change" breakpoint active in your debug session. – Richard Critten Jan 18 '18 at 15:23
  • 1
    it's probably dumb question, but did you use something like "top" to monitor system resources? Isn't the debug version running out of free memory much more quickly, going into swap space? That may hurt performance even 100+x times in worst scenarios (like about couple of GB of memory going back-and-forth to swap). When the process is "frozen" is the CPU near 0 or 100%? Is there free memory? Is there swap growing? – Ped7g Jan 18 '18 at 15:26
  • There are several debuggers named dbg, but none seem to fit in your report. Do you mean gdb perhaps? – n. m. could be an AI Jan 18 '18 at 15:50
  • Thanks contributors for your reactions/answers.... Concerning your (preliminary) answers: -- sorry for the confusion: of course the debugger I mean is "gdb" and nog "dbg" (I'm not dyslectic, but this was an involuntary dyslectic moment of me....) -- I have no conditional breakpoints, skipping all breakpoints while "frozen" in debug mode has no visible effect -- the CPU is about 90% – SoHerman Jan 29 '18 at 15:21
  • To elaborate my previous reaction some more: yes, I used "top" to monitor the system resources..... the behaviour/occupancy of "free/swap memory space was somewhat erratic during processing of the large drawing files, but it SEEMED that still sufficient space should be available... This lead to an additional question: how can I determine that "the amount of swapping or the consumed swapping space" has reached a limit or "ceiling" (with respect of what is or should be available for that)? – SoHerman Jan 30 '18 at 11:20

0 Answers0