Recently I have lost some of my debug functionality in Delphi 2007.
Specifically, the Watch List Window is completely disable as are all but a
few of the Watch List's popup menu items. The only menu items that are
enabled are
Add Group...
Show Column Headers
Stay on Top
Dockable
This is the case in the ide and the program running or not running
Breakpoints work as does tooltip expressions at breakpoint.
In Tools | Options , Code completion, Error Insight, Block Completion and
Code Template Completion are unchecked, all other options are checked.
In Tools | Options, Debugger Options are set Integrated Debugging and
Automatically close files implicitly...' checked , all others unchecked.
In Project | Options (Compiler), Optimization unchecked All Debugging
section items checked with exception of 'definitions only'
Conditional Defines are DEBUG;madExcept
When a breakpoint is hit, the Watch List windows shows 'Evaluating...' for
each Watch Name. BTW, the watch names were entered some time ago when all
debugging features were working.
After a period of attempted debugging while at a breakpoint (stopped), the
Run button on toolbar becomes disabled and I have to click 'Run | Program
Reset' on the menu at which time madExcept
throws the following exception from the IDE:
date/time : 2014-09-28, 09:08:17, 855ms
computer name : JOHNTAYLOR-LAP
user name : JT <admin>
registered owner : Microsoft / Microsoft
operating system : Windows 7 x64 build 7600
system language : English
system up time : 10 days 22 hours
program up time : 3 days
processors : 8x Intel(R) Core(TM) i7 CPU Q 840 # 1.87GHz
physical memory : 7944/16308 MB (free/total)
free disk space : (C:) 83.99 GB
display mode : 1024x768, 32 bit
process id : $2994
allocated memory : 354.77 MB
command line : "C:\CodeGear RAD Studio\CodeGear\RAD Studio\5.0\bin\bds.exe" -np
executable : bds.exe
current module : madExcept_.bpl
exec. date/time : 2007-12-11 15:04
version : 11.0.2902.10471
compiled with : Delphi 2006/07
madExcept version : 4.0.6
callstack crc : $f8d6ff12, $83616f26, $cd9b05a3
exception number : 1
exception class : EListError
exception message : List index out of bounds (0).
main thread ($325c):
20032558 +03c rtl100.bpl Classes 3525 +3 TInterfaceList.Put
2087a8f4 +008 dbkdebugide100.bpl Debug 6414 +1 TThread.RemoveNotifier
20aa3b13 +043 coreide100.bpl WatchWin 1543 +1 TWatchWindow.EvaluteComplete
20878cf9 +0fd dbkdebugide100.bpl Debug 5564 +12 TThread.EvalComplete
20877660 +02c dbkdebugide100.bpl Debug 4871 +2 TDbkApiEvent.Send
208784c8 +024 dbkdebugide100.bpl Debug 5300 +2 TDebugKernel.apiComplete
2013a81a +012 vcl100.bpl Controls 4039 +1 TControl.ScreenToClient
209b6b21 +065 coreide100.bpl EditorControl 6744 +3 TCustomEditControl.WMNCHitTest
7759e74d +078 ntdll.dll RtlAnsiStringToUnicodeString
76977b0a +016 USER32.dll CallWindowProcA
20885499 +039 dbkdebugide100.bpl Debug 11455 +3 TDebugger.DBKWndProc
20040e4c +014 rtl100.bpl Classes 11583 +8 StdWndProc
7696810d +00a USER32.dll DispatchMessageA
Can anyone help me get this straightened out ? This started suddenly about
a month ago and not pursuant to any new component installation that I am
aware of.
I had the same problem in BDS2006. And I found a very simple solution that worked for me. Open your project desktop-file (.dsk). Go to the watches section. I just removed some unwanted watches (don't forget to adjust the count), started Delphi again and my watches and menu-items were enabled.
Related
As already answered in this question:
JVM_FindSignal function continuously allocates native memory
jemalloc reporting leaks from JVM_FindSignal is related to missing debug symbols. I certainly have debugging symbols installed, see:
rbs42#rbs42-VirtualBox:/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server$ gdb libjvm.so -ex 'info address UseG1GC'
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from libjvm.so...
Reading symbols from /usr/lib/debug/.build-id/16/240e0172c3fc0dd6e974325c8ad1d93723ccac.debug...
(No debugging symbols found in /usr/lib/debug/.build-id/16/240e0172c3fc0dd6e974325c8ad1d93723ccac.debug)
Installing openjdk unwinder
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 52, in <module>
class Types(object):
File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 66, in Types
nmethodp_t = gdb.lookup_type('nmethod').pointer()
gdb.error: No type named nmethod.
Symbol "UseG1GC" is at 0xd189b2 in a file compiled without debugging.
still my jeprof output looks as following:
rbs42#rbs42-VirtualBox:/media/rbs42/data/Gebos/RBS42/run/sms50$ jeprof --show_bytes /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java jeprof.22104.0.f.heap
Using local file /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java.
Using local file jeprof.22104.0.f.heap.
Welcome to jeprof! For help, type 'help'.
(jeprof) top
Total: 33502504 B
20958503 62.6% 62.6% 21342909 63.7% JVM_FindSignal
8388608 25.0% 87.6% 8388608 25.0% SNX11B1A
1481379 4.4% 92.0% 1481379 4.4% inflate
1151253 3.4% 95.5% 1151253 3.4% Java_java_util_zip_ZipFile_getZipMessage
426303 1.3% 96.7% 426303 1.3% SNE00B1A
404065 1.2% 97.9% 404065 1.2% inflateInit2_
253077 0.8% 98.7% 20393297 60.9% SUNWprivate_1.1
176271 0.5% 99.2% 176271 0.5% std::__throw_ios_failure
131713 0.4% 99.6% 131713 0.4% _dl_new_object
131328 0.4% 100.0% 131328 0.4% _dl_check_map_versions
(jeprof)
Is there anything else to consider?
It turns out that
openjdk-8-dbg package installs files with debug symbols into /usr/lib/debug/.build-id
jeprof looks for debug symbols in /usr/lib/debug/{FULL_SO_PATH}
So, it's a combination of a bug in jeprof that does not parse .note.gnu.build-id section, and a problem of the dbg package that does not include full path symlinks to debug libraries.
To work around this, you may create the corresponding symlink manually:
ln -s /usr/lib/debug/.build-id/16/240e0172c3fc0dd6e974325c8ad1d93723ccac.debug /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so
(the file names are taken from gdb output)
However, even when jeprof is able to read debug symbols, this doesn't often help in case of Java applications. The problem is that jemalloc doesn't know how to unwind Java stacks. See this presentation for an example.
Consider trying async-profiler that can show mixed Java+native stacks. Profiling malloc, mprotect and mmap calls with async-profiler can be helpful in finding native memory leaks in Java applications. See this answer for details.
Here is a patch for jeprof that makes it smarter about finding debug symbols. It's based on #apangin's answer.
https://github.com/jemalloc/jemalloc/pull/2059/files
Every time I try to do anything with Code Analysis, Visual Studio crashes. The event viewer shows the crash is caused by an invalid window-splitter size.
Stacktrace:
Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentOutOfRangeException
at System.Windows.Forms.SplitContainer.set_SplitterDistance(Int32)
at Microsoft.VisualStudio.CodeAnalysis.AdvancedRuleSetEdit.LoadHelpPaneSizeString(System.String)
at Microsoft.VisualStudio.CodeAnalysis.AdvancedRuleSetEdit.LoadHelpPaneSettings()
at Microsoft.VisualStudio.CodeAnalysis.AdvancedRuleSetEdit.SplitterResized(System.Object, System.EventArgs)
at System.Windows.Forms.Control.OnResize(System.EventArgs)
at System.Windows.Forms.Control.OnSizeChanged(System.EventArgs)
at System.Windows.Forms.Control.UpdateBounds(Int32, Int32, Int32, Int32, Int32, Int32)
at System.Windows.Forms.Control.UpdateBounds()
at System.Windows.Forms.Control.WmWindowPosChanged(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.ScrollableControl.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.ContainerControl.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.SplitContainer.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr, Int32, IntPtr, IntPtr)
Procmon shows this value is stored in the private registry bin file.
Deleting the window settings for Code Analysis fixes the cause of the crash. You may need to do this every time you close Visual Studio.
Export from the private registry bin:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\vs2019\Software\Microsoft\VisualStudio\16.0_ad070b97\CodeAnalysis]
"RuleSetMRUList"=""
"RuleSelectionControl_Settings"="True,True,True,7,2,0,True,0;True;0.385#1;False;0.160#2;True;0.429#3;False;0.160#4;False;0.100#5;True;0.186#6;False;0.150#7;False;0.150#"
"RuleSetEditorHelpPaneSize"="573,573"
If you are running into this, to resolve:
// put your instance id in the next line instead of ad070b97
cd C:\Users\Administrator\AppData\Local\Microsoft\VisualStudio\16.0_ad070b97
reg load HKLM\vs2019 privateregistry.bin
reg delete HKLM\vs2019\Software\Microsoft\VisualStudio\16.0_ad070b97\CodeAnalysis /v RuleSetEditorHelpPaneSize
reg unload HKLM\vs2019
Fixed in latest VS 2019 versions
This is caused by the scaling options for your display. (the part that makes text and icons larger.)
Reset your scaling to 100% and it will show the window. There are other control in vs that cause issues as well, but this one crashes it. If it's larger then 100, various parts of vs 2017 don't work. This crashes it, forms designer complains, and an error message shows up in the Solutions properties page. (not project properties)
Seems Microsoft never got around to testing or fixing this.
Test it to confirm.
Since I installed Delphi XE7 I have this nasty crash as shutdown:
Description:
Stopped working
Problem signature:
Problem Event Name: APPCRASH
Application Name: bds.exe
Application Version: 21.0.17707.5020
Application Timestamp: 545bd62d
Fault Module Name: rtl210.bpl
Fault Module Version: 21.0.17707.5020
Fault Module Timestamp: 545bd940
Exception Code: c0000005
Exception Offset: 00016a9c
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
After I click the 'Close program' I get:
Exception EAccessViolation in module rtl210.bpl at 00016A9C.
Access violation at address 50066A9C in module 'rtl210.bpl'. Read of
address 075F2AF8.
I checked the call stack but it doesn't really makes any sense.
To see the call stack I started Delphi, then in 'Load process' I entered Delphi's path ( "C:\Delphi\XE7\bin\bds.exe" ).
I cannot set the '-p delphi' parameter in 'Parameters' box because when the second Delphi process is started it will complain that it cannot access the license file (which is blocked by the first Delphi process).
Call stack:
:50066a9c rtl210.#System##IntfClear$qqrr44System#%DelphiInterface$17System#IInterface% + 0x10
:08baffdd fmx210.#System#Generics#Collections#%TList__1$56System#%DelphiInterface$29Fmx#Behaviormanager#IListener%%#SetCount$qqri + 0x49
:50061099 rtl210.#System##Halt0$qqrv + 0xb1
:77378bd4 ntdll.wcsncmp + 0x88
:77342710 ; ntdll.dll
:7737cb10 ntdll.LdrUnloadDll + 0x4a
:753b8be4 KERNELBASE.FreeLibrary + 0x82
:2063a191 coreide210.#Exptmain#TExpertLib#$bdtr$qqrv + 0xa9
:5005f10b rtl210.#System#TObject#Free$qqrv + 0xb
:5070ba40 vcl210.#Vcl#Forms#TCustomForm#$bdtr$qqrv + 0x58
:210f57c0 designide210.#Deskform#TDesktopForm#$bdtr$qqrv + 0x40
:761aee1c kernel32.BaseThreadInitThunk + 0x12
:7738399b ntdll.RtlInitializeExceptionChain + 0xef
:7738396e ntdll.RtlInitializeExceptionChain + 0xc2
It says something about FMX but I never do FMX projects (still too unripe to be used). So I disable it.
What could cause the crash?
This is a Delphi bug
SOLUTION: Enable 'FMX Standard Components' package.
Details: I turned out that I had the 'FMX Standard Components' package disabled - Seems logical to disable such a large library since I don't use it.
Well... Delphi don't like that! I enabled the library back and now I have no crash!
I could have delete the question since nobody answered posted any answer but I thought it will be useful to keep it. It documents a very important feature of Delphi: crash when the developer won't use FMX lib :)
I am trying to compare the performance of a specific F# benchmark running on .NET and Mono 2.10.2 (Windows 7, 64-bit). I took the Spectral-Norm benchmark from the Benchmarks Game followed the traditional SO advice of using System.Diagnostics.StopWatch for benchmarking C# and added the lines 4, 89-90, and 93-95 at this link. I compiled this code in Visual Studio 2010 (For runtime 4.0, not client profile, any CPU, with optimize code and tail calls turned on). The compiled code runs just fine on .NET (including inside VS), but when I run the .exe on Mono with "mono shootout_spectralnorm.exe" I get the following error (repeated in the fssnip.net link):
Unhandled Exception: System.TypeInitializationException: An exception was thrown
by the type initializer for System.Diagnostics.Stopwatch ---> System.InvalidPro
gramException: Invalid IL code in System.Diagnostics.Stopwatch:.cctor (): method
body is empty.
--- End of inner exception stack trace ---
at Program.main (System.String[] args) [0x00000] in <filename unknown>:0
The strange thing is, when I remove the lines I had added (lines 4, 89-90, and 93-95, which relate to the timing part of the benchmark), the error goes away on Mono, and it acts just like it does on MS .NET. This is just baffling me. I set all of the referenced assemblies in VS to be copied locally, so they should be visible to Mono, but there could be some precedence issue with different assemblies in the GAC that have the same name as the ones in the local folder. Has anyone encountered this issue or a similar one, especially on Windows Mono? If so, or if you think you know how this problem could be fixed, I hope you can help me resolve it.
Reference Assemblies do not (often) have code - they are API signatures only (enough info for the compiler to reference them at design-time/compile-time). You need to copy the runtime assemblies, not the reference assemblies, in order to run it. (You'll often find the runtime assemblies in the GAC.)
Here are measurements for FSharp-2.0.0.0 spectral-norm #2 (Intel Q6600 quad-core, MS Vista 32 bit)
fsc CPU s Elapsed s
500 0.281 0.337
3000 4.883 1.453
5500 15.85 4.212
2.10.2 CPU s Elapsed s
500 0.343 2.222
3000 4.836 3.361
5500 15.912 6.153
C:/Mono-2.10.2/bin/mono.exe C:/FSharp-2.0.0.0/bin/fsc.exe --platform:x86
--optimize+ --out:spectralnorm.exe spectralnorm.fsharpmono-2.fs
C:/Mono-2.10.2/bin/mono.exe --gc=sgen spectralnorm.exe 5500
Now the benchmarks game spectral-norm on MS Vista demo, includes F# on Mono.
I've been testing some D2006 code using Rave reports on a virtual machine and have found the app hangs when I generate a PDF report if there is no printer installed. The hang occurs here:
exception message : The application seems to be frozen.
main thread ($108):
005c5e62 +106 MyApp.exe RpRPTF SimpleTextWidth
006198f7 +31b MyApp.exe RpMemo TMemoBuf.GetLine
0061a44a +086 MyApp.exe RpMemo TMemoBuf.MemoLinesLeft
005cba28 +014 MyApp.exe RpBase TBaseReport.MemoLines
00672e8e +072 MyApp.exe MyAppReports PrintReportParagraph
00677f73 +acb MyApp.exe MyAppReports PrintSummaryReportBody
0066b208 +010 MyApp.exe MyAppMainForm TMainForm.RvSystemSummaryReportPrint
005c6f35 +015 MyApp.exe RpBase TBaseReport.PrintEvent
005c8066 +03a MyApp.exe RpBase TBaseReport.Execute
0060a299 +125 MyApp.exe RpSystem TRvSystem.GenerateReport
0060a52a +07e MyApp.exe RpSystem TRvSystem.Execute
0067d364 +0ac MyApp.exe MyAppReports DoPrintSummaryReport
0067d64d +1d5 MyApp.exe MyAppReports ProduceReports
0066e966 +1e6 MyApp.exe MyAppProcessing ProcessMyAppData
0066ab9b +0d7 MyApp.exe MyAppMainForm TMainForm.DoProcessData
and no doubt is something to do with a page width of zero confusing the code that is calculating how many lines it can fit across the page or some such.
The thing is I'm writing a PDF - not printing - so I can't see why not having a printer should trip this code up (Acrobat Reader is installed). If I install a printer it behaves. Why do I need a printer installed (the app could be installed on a workstation without a printer installed - having an error message that says: "You can't generate a PDF report unless you install printer" seems a bit clunky) ?
This is a long-standing bug in Rave Reports. It has to do with no default printer being installed. I'll look for links to old Borland/CodeGear forum posts (CodeNewsFast doesn't seem to be responding right now). There was a problem with it making an assumption about a printer being present. I don't know if it's been fixed in the most recent versions of Rave. (D2006 was quite a while back.)
If I remember correctly, the solution was to install the text driver to a "mock" printer. This allows Rave to continue to function.