[ABANDONED] Debug error: Laz trunk and 1.0.6 lazarus / 12-Debugger ---------------------------------------------------------------------- BigChimp · 2013-02-26 09:11 Hi all (& Martin ), Have a problem with the attached project with a single breakpoint set when trying to run the debugger. Laz 1.0.6, FPC x86 2.6.0, GDB 7.2, Windows x64 "The debugger encountered an error when trying to run/step the application Warning\nCannot insert breakpoint 8.\nError accessing memory address 0x3d: Input/output error.\n" Debug log attached for a run with 1.0.6. Similar error seems to occur with Lazarus trunk r40360, FPC 2.7.1 x86. Operator error ? Thanks, BigChimp Edit: removed test program; new, simpler test program attached further below. ---------------------------------------------------------------------- Martin_fr · 2013-02-26 15:23 - Settings are all ok - Also happens with 2.6.2 on 32 bit, GDB 7.2.1 - Works (but not as you would expect) with 32 bit gdb 7.5.1 (But see notes below) Quote\nCannot insert breakpoint 8.\nError accessing memory address 0x3d: Input/output error. For some reason the address is not relocated when the program is loaded. I made 2 observations: *** 1) GDB 7.2.1 does show "line info" (blue dots) on that line. Indicating that the code is used. GDB 7.5 does indicate this code is not used (never called) (So it gives no error, but the breakpoint will not be there either) If the code is not used, and possible not linked into the exe, then those relocation errors do happen. IIRC there is a bug, that line info for none used code is included, even if the code is not. Seems that older GDB fails with that. *** 2) I also noted, that if I rename the file, all works fine. So I guess that the original file with the same name is still partly used, and some methods in the exe are taken from the original file. ----------------------------------------------- I do not know what you try to do: but simply creating a file with the same name as in the fpc package, will not redirect all calls into your version. Only calls that are made in your units (including the ones with the copied name). You also use "fpimage" but from the original fpc location. Any call this makes to fpreadtiff, may (not sure if all, but at least some) still go to the original file. Besides that: this kind of double file names can lead to lots of troubles. ---------------------------------------------------------------------- BigChimp · 2013-02-27 06:57 Thanks. Well, as my version of fpreadtiff.pas registers itself with the image subsystem I would expect that mechanism to work - either use my version or the built-in version, depending on what is registered earlier. Of course, that does leave fpctiffcmn.pas It's strange, because the compiled exe does show the new behaviour (uses the modifications I made in at least fpreadtiff.pas) when processing files. Also the User's Guide, 3.1.2 says unit searching happens in the current directory first - hoping that is my program directory so my units should override any FPC units!? BTW the result, after fiddling some more with what bits go where,  is in Quoter23664 | mattias | 2013-02-26 15:58:51 +0100 (di, 26 feb 2013) | 1 line tiff: read 1-bit white/black images, patch 23959 ---------------------------------------------------------------------- Martin_fr · 2013-02-27 13:10 Maybe it uses yours. IIRC I have seen big troubles with such duplicates names in the past. If it does yours, you can fix it, by changing the unit (and file-) name. However, then somewhere debug info is wrong (and that you need to take to the fpc mail list. OR gdb has issues reading it (not sure, if the fpc packages have some basic (-gl) debug info. If so this may irritate. It is also possible Lazarus does not handle the double existing of the same file-name in debug info (*IF* really that is the case). Lazarus (in many cases) attempts the full (d:\full path...) filename. But this does not always work, and then it will always try without path. In your log, it uses full path for "line info" (blue dots). But breakpoint always only uses no-path version. Then again: even if both files had debug info: One of them must have incorrect debug info, because it wasn't relocated: "is at address 0x3d but contains no code" As for my tests, with GDB 7.5. gdb 7.5 says that there is no code on the line of your breakpoint (full filename). gdb 7.5 reports the path to the file found, if a breakpoint is set to afile with no path specified. So either debug info by fpc is wrong, or gdb broken. Is your TFPReaderTiff.ReadImgValue modified, or have you put a writeln in there? Would you notice if it was or was not used over the original? ---------------------------------------------------------------------- BigChimp · 2013-02-27 14:22 Thanks for the clear explanation, Martin. I understand. Yes, my fpc trunk has debug info compiled into it: "-gw2 -godwarfsets -gl". I'll try without that as well. Now you talk about irritation: I do seem to remember there was a bug where the debug options needed to be exactly the same; if not, debug info would get messed up. Yes, TFPReaderTiff.ReadImgValue was modified compared to the original (it reads images with bitcount 1 which didn't occur in the original). In the end, you notice the difference because a tiff image can be correctly read instead of generating an exception (in TFPReaderTiff) because 1 bit images are not supported I can modify the test project a bit: I'll use the current trunk version and add some debuglns in TFPReaderTiff.ReadImgValue so we can see if that code gets hit. Then use an 8 bit tiff example image that should work with both trunk and 2.6.0 so it's easier to compare. Thanks a lot for your help & I'll post back... may be some time though. ---------------------------------------------------------------------- BigChimp · 2013-02-28 08:14 It gets stranger and stranger. With both Laz trunk/FPC 2.7.1/GDB 7.2 and Laz 1.0.6/FPC 2.6/GDB 7.2 setting breakpoints on one part of the custom fpreadtiff.pas code works; setting it on another doesn't. See notes in attached project - please let me know if you need more info... I'll ask on the fpc ML whether this setup (overriding units in another directory) is indded supposed to work. ---------------------------------------------------------------------- Martin_fr · 2013-02-28 14:59 I checked your new code again (just with GDB 7.5): It claims, that the exe contains no code for "TFPReaderTiff.ReadImgValue" (from your unit). It does not matter if that claim is right or wrong. If the claim is wrong, it still can not be fixed in the IDE. ------- I put a writeln in there. And it gets called. So gdb/fpc or linker is wrong. It seems to be the linker. At least on windows. If I use -Xe (external linker) then it works. So you an check with the FPC team if this is a known issue with the build in linker, or if you should report it as a bug. ---------------------------------------------------------------------- BigChimp · 2013-02-28 15:02 Thanks, I'll copy your post to the mailing list. ---------------------------------------------------------------------- BigChimp · 2013-03-01 08:09 Quote from: Martin_fr on February 28, 2013, 03:59:30 pmI checked your new code again (just with GDB 7.5): It seems to be the linker. At least on windows. If I use -Xe (external linker) then it works. Hmm, using -Xe with GDB 7.5 [1] doesn't work for me: nothing is hit (program just runs). I added -Xe to project options/other/custom options. Test gives: Code: [Select]C:\development\fpctrunk\bin\i386-win32\fpc.exe  -MObjFPC -Scghi -Cirot -gw2 -godwarfsets -gl -va -FiD:\Reinier\Documents\Source Code\fpc_laz_patch_playground\debugtest\lib\i386-win32 -FuD:\Reinier\Documents\SourceCode\fpc_laz_patch_playground\debugtest\ -FUD:\Reinier\Documents\SourceCode\fpc_laz_patch_playground\debugtest\ lib\i386-win32\ -l -Xe C:\Users\Reinier\AppData\Local\Temp\testcompileroptions.pas [1] http://www.drangon.org/mingw/mirror.php?num=2&fname=mingw-w32-bin- i686-20130104.7z ---------------------------------------------------------------------- Martin_fr · 2013-03-01 15:41 Hm odd. Just confirming, you are on a 64 bit cpu, but you use compile and debug 32 bit? Maybe you have a different version of the external linker. - I have ld.exe 2.21.1 (which comes with 2.6.0). - my gdb is from mingw Since this is an issue in fpc and the linker, and maybe gdb, I have no plans to test all the possible combinations. However, if you attach another log, I can look if it is the same issue. If it is, then your only option is to avoid duplicate filenames (and/or wait until it is fixed in fpc, linker, gdb, or any combination of them / I am not going to find out which of them) ---------------------------------------------------------------------- BigChimp · 2013-03-01 15:52 Quote from: Martin_fr on March 01, 2013, 04:41:26 pmJust confirming, you are on a 64 bit cpu, but you use compile and debug 32 bit? Correct. Quote from: Martin_fr on March 01, 2013, 04:41:26 pmMaybe you have a different version of the external linker. - I have ld.exe 2.21.1 (which comes with 2.6.0). Yep, I have ld 2.22 (from fpc trunk probably) for Laz trunk+fpc trunk However, my Laz 1.0.6+fpc 2.6.0 has the regular ld.exe 2.21.1 Quote from: Martin_fr on March 01, 2013, 04:41:26 pm- my gdb is from mingw As indicated, I downloaded the mingw 7.5 gdb.exe from drangon and used it today in laz trunk+fpc trunk; otherwise & normally I use gdb 7.2 as supplied by the Laz installer. Quote from: Martin_fr on March 01, 2013, 04:41:26 pmSince this is an issue in fpc and the linker, and maybe gdb, I have no plans to test all the possible combinations. However, if you attach another log, I can look if it is the same issue. If it is, then your only option is to avoid duplicate filenames (and/or wait until it is fixed in fpc, linker, gdb, or any combination of them / I am not going to find out which of them) I understand. Haven't received any answer on the ML, so further testing wouldn't be useful anyway, I think. For my production code, I've indeed renamed fpreadtiff etc, renamed some classes. Haven't tested setting breakpoints & debugging yet... Thanks, Martin!