Here is my current problem:
I have a source unit that I have written (or should say, converted from C) that is about 2,500 lines total, and about 248K in size. This should be well within the limits of the IDE, as there are plenty more units out there that are much larger, and they debug/single step just fine.
Regardless of what I do, I cannot get any of my breakpoints in THIS unit (only) to activate, all other units are fine. The breakpoints are NOT set on no-op lines, or anything like that. And yes, I do have the debug options set (all of them in fact, I have even tried with remote debugging symbols). I have removed the dcu for this unit multiple times, and even checked sizes when compiled with debug vs non debug (148K/96K).
The only thing that makes this unit unique is the fact that there is a LARGE amount of constant data declared in it, mainly in the form of record constants (and I do mean large, about 100K worth).
Before I go splitting this source across multiple units (I would REALLY rather not do this, as it does compile and execute correctly), does anyone have any ideas/suggestions?
All comments are welcome, so long as you don't tell me to set the debug options flag in the compiler options ;-)
Thanks in advance,
Russell
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Meikl,
I set the breakpoint at design time and its red (active), but as soon as I "Run..." the program it becomes green (X in it, indicating not active).
And no, I cannot step into the unit. I even tried using :
DebugBreak; // generate an INT3
Which DID force the CPU window to come up (and I can trace in there), but no lines in the source code get hi-lighted.
Very strange....
I have never run into anything quite like this. ;-)
Regards,
Russell
aikimark,
The static assignments are in the form of record constants (as noted above), so please elaborate further. How would I go about storing the following, then loading it?
For example (one of the smaller ones).
const
tbl_fpuDF_00BF: Array [0..7] of instr =
((table: 0; mnemFlg: INS_FPU; destFlg: ADDRMETH_M or OPTYPE_w or OP_W; srcFlg: ARG_NONE; auxFlg: ARG_NONE; cpu: cpu_80387; mnemonic: 'fild'; dest: 0; src: 0; aux: 0),
(table: 0; mnemFlg: 0; destFlg: ARG_NONE; srcFlg: ARG_NONE; auxFlg: ARG_NONE; cpu: cpu_80387; mnemonic: #0; dest: 0; src: 0; aux: 0),
(table: 0; mnemFlg: INS_FPU; destFlg: ADDRMETH_M or OPTYPE_w or OP_W; srcFlg: ARG_NONE; auxFlg: ARG_NONE; cpu: cpu_80387; mnemonic: 'fist'; dest: 0; src: 0; aux: 0),
(table: 0; mnemFlg: INS_FPU; destFlg: ADDRMETH_M or OPTYPE_w or OP_W; srcFlg: ARG_NONE; auxFlg: ARG_NONE; cpu: cpu_80387; mnemonic: 'fistp'; dest: 0; src: 0; aux: 0),
(table: 0; mnemFlg: INS_FPU; destFlg: ADDRMETH_M or OPTYPE_fb or OP_W; srcFlg: ARG_NONE; auxFlg: ARG_NONE; cpu: cpu_80387; mnemonic: 'fbld'; dest: 0; src: 0; aux: 0),
(table: 0; mnemFlg: INS_FPU; destFlg: ADDRMETH_M or OPTYPE_q or OP_W; srcFlg: ARG_NONE; auxFlg: ARG_NONE; cpu: cpu_80387; mnemonic: 'fild'; dest: 0; src: 0; aux: 0),
(table: 0; mnemFlg: INS_FPU; destFlg: ADDRMETH_M or OPTYPE_fb or OP_W; srcFlg: ARG_NONE; auxFlg: ARG_NONE; cpu: cpu_80387; mnemonic: 'fbstp'; dest: 0; src: 0; aux: 0),
(table: 0; mnemFlg: INS_FPU; destFlg: ADDRMETH_M or OPTYPE_q or OP_W; srcFlg: ARG_NONE; auxFlg: ARG_NONE; cpu: cpu_80387; mnemonic: 'fistp'; dest: 0; src: 0; aux: 0));
--------
wframsay,
I CAN split it, but was hoping to avoid doing so. And I'm also not sure how much I'll have to split it. I will look into this though
--------
Regards,
Russell
No, have tried deleting the dcu multiple times with no success. :-(
And looking over the code some more, it is very difficult to split cleanly due to the dependancies invoved with the tables/constants/structure
I am thinking that I could run this as it currently is, then take the tables and dump them to memory, then to disk. Then, similar to what aikimark suggested, store them as RC_RTDATA resource streams. If i change the tables from const to var, then I could Move(...) the table data into the tables at runtime during the initialization. Not the best of solutions, but its what I am currently looking at now.
Thanks for the comments so far,
Russell
One of our pieces of software generates vast amounts of data which is then used to effectively embed data within software. It is not of constant form, but the source file size is well over 1Mb. I can step through with no problems.
Sample extracts:
var
_ADIDCOT, _ADNDID, _ADNMNE, _ADNMNW, _ADNOXFD, _ADNRLFE, _ARLFDID, _AUFFDN,
_AUFFUP, _AUPDID, _AUPMNE, _AUPMNW, _AUPOXFD, _AUPRLFE : TARS;
_B0901, _B0903, _B0904, _B0905, _B0906, _B0907, _B0911, _B0912,
_B0913, _B0914, _B0916, _B0918, _B0920, _B0921, _B0922, _B0923,
_B0924, _B0925, _B0926, _B0928, _B0931, _B0933, _B0935, _B0936,
_B0937, _B0938, _B0940, _B0941, _B0942, _B0944, _B0947, _B0949,
_B0951, _B0952, _B0954, _B0961, _B0963, _B0966, _B0973, _B0976,
_ADIDCOT := TARS(ARSList.Objects[0]);
_ADIDCOT.ID := 'ADIDCOT';
_ADNDID := TARS(ARSList.Objects[1]);
_ADNDID.ID := 'ADNDID';
_ADNMNE := TARS(ARSList.Objects[2]);
_ADNMNE.ID := 'ADNMNE';
_ADNMNW := TARS(ARSList.Objects[3]);
_ADNMNW.ID := 'ADNMNW';
_ADNOXFD := TARS(ARSList.Objects[4]);
_ADNOXFD.ID := 'ADNOXFD';
_ADNRLFE := TARS(ARSList.Objects[5]);
_ADNRLFE.ID := 'ADNRLFE';
_ARLFDID := TARS(ARSList.Objects[6]);
_ARLFDID.ID := 'ARLFDID';
_D10.InitData(367, 14,
'CHOLSEY',
True);
_D11.InitData(795, 41,
'DOWN MAIN',
True);
ad finitum.
--
Earlier versions of Delphi had a limit of the number of constants in one unit. I am not aware if this limitation still exists or not - I would hope it doesn't!
Geoff M.
DragonSlayer,
I also had the same though earlier in regards to this, as I have previously run into the type of issue you mention. (mainly happens when I transcribe C code over)
Thus, a few days ago I dumped the pas file and ran it though 2 parse phases, the first was to ensure all line ends were CRLF and the second was to remove all TAB chars from the source. Still no joy at this point.
Russell
Meikl - Windows XP.
Geoff - I realize that tabs aren't supposed to be an issue, but I wanted to make sure that this source was as "clean" as possible, in order to rule out all possibilites. Due to the dependancies, a split is not trivial. (am almost done dumping the tables to an rc format which I can compile to res).
As I said, its just this unit. All other included units in this project will let me debug/single step/etc..
Will let you know the results of resource streams/and var tables in a bit.
Russell
I was initially thinking of changing const to var and using the resource file streaming that you already know about.
I was about to suggest the use of $Includes for your constants, but that has also been suggested.
Thinking outside of the box, I wonder if you might make a meta-unit with multiple $Includes for multiple segmented versions of your current unit.
well, xp, not far away from w2k
would be a worth try
http://codecentral.borland
maybe also just unusual
meikl ;-)
Hi Russel,
I have had this problem in my old Pascal days, whereby if I have long declaration, the debugging doesn't work.
e.g.
if I have
const
MyLongArray: array[1 .. 3] of string = (
"This is a long string, a very very long string, I guess... and what do we do about it";
etc. etc.
Now, I'm not trying to touch into some memory/variable issues here... but more on to the length of the code. I recall that there used to be a limit to the length of a statement... and your constant declaration qualifies as only a *single statement* regardless of how many lines you break it into.
So, perhaps it's a limitation in Delphi as well?
DragonSlayer.
Well,
I have this working and can now debug the unit code. What I ended up doing is writing a routine that built an RC file and then dumped all my tables (record constants) into this resource file. After converting the rc->res, and {$R including the res, and finally loading the tables, it all works... (seems like way to much work).
To satisfy my own curiosity, I started from scratch again and started removing the tables one by one, changing the const declaration over to var (empty table). It would appear that 64K is the magic number in this scenario. As to the why, I can't really say....
Once I got the total constant data under 64K, then I was able to debug just fine.
I do appreaciate the comments and suggestion that were offered by all, but I am going to give the lion's share of the points to aikimark, as his suggestion got me down the right path, with the least amount of work. (It would have taken MUCH longer for me to split this apart and get it all working again).
Thanks to all,
Russell
Hi
I guess there is a limit to the number of symbols the debugger can handle in a unit (also in Delphi 7).
We experienced a problem in a unit with a class containing about 800 properties with associated getter/setter methods.
After compiling/building the "blue dots" on the left side of the editor window would disappear around the middle of the unit.
Getting rid of the getters/setters by using index properties solved the problem.
So I think the solution is to reduce the number of symbols in the unit.
Henrik
Business Accounts
Answer for Membership
by: kretzschmarPosted on 2004-02-25 at 06:53:31ID: 10450819
no suggestion yet,
but if you set a breakpoint,
does this breakpoint remain at runtime, or becomes it an x on it?
can you step into your unit?
meikl ;-)