Link to home
Start Free TrialLog in
Avatar of GTDGuy
GTDGuy

asked on

Breakpoints not valid when debugging application in Delphi 2007

Have an application (just an EXE) that I need to debug on a remote machine. This is the first time I've had to do this with Delphi 2007, so its probably something stupid but I've checked just about everything I can think of. App runs fine locally, has "blue dots" and break points work. Run remotely the dots disappear and the break points become invalid. Here is what I've checked so far:

1) Rmtdbg105.exe is running.
2) App was compiled with linker set for remote Debug symbols and optionally TD32 debug info. RSM file is being generated.
3) Have integrated debugging turned on AND as I said, breakpoints, etc. work when I  run locally.
4) Launching via Run|Load Process|Remote|Load w- execute on load checked.
5) It is running on remote machine and I can interact with UI on remote machine just fine. Killing process from IDE, kills app on remote, etc.

Ok, that is about all I can think of right now as far as settings, etc. Any ideas about what I'm missing.

Greg
Avatar of developmentguru
developmentguru
Flag of United States of America image

I have had more luck running the application on the remote machine and using Run | Attach To Process.  When the dialog comes up I select the remote machine and the process to attach to.  Try this and let me know if it does any better.
Avatar of GTDGuy
GTDGuy

ASKER

Tried attach and same difference.
Did you put the RSM file in the same directory as the executable on the remote machine?
Avatar of GTDGuy

ASKER

Sorry, that was not clear from above, but yes. It is in same directory.
Ok, having rebuilt your application on your end and having copied the RSM file to the clients side... bear with me on this... did you copy the rebuilt executable over as well?  The lack of dots on in the IDE means that it has no way to map the code you are seeing to the executable it is attached to.  This could be caused by the fact that their version of the executable has no symbol information.  If you tell me that you did copy the executable file to their location, and you are sure there is not another copy being run from their system, I will look into it further.
Avatar of GTDGuy

ASKER

Actually the remote program files directory is mapped to a letter like "M:" and that is what the exe output directory is set for. So both the EXE and RSM end up there automatically.  They are both there and with the proper timestamps so I know all is well in that regard. The actual running is on the "C:"( local drive of the remote machine). I also manually change a log string with current time just before compile to ensure that what copy I think is running is actually running and it is.
OK, very good.  Next I would like to see a screen shot of the Project options for both the compiler and linker.  Please be patient through this as I will need to see these options for myself in order to figure out next steps.
Avatar of GTDGuy

ASKER

Ok. I have switched gears for a bit, but will get you screen shots within 24hrs.
Avatar of GTDGuy

ASKER

OK, sorry for the delay. I've uploaded a zip with several PNGs and a "BMP" which needs to be renamed to "AVI".  The avi shows in real time the blue dots going away as a "Load" takes place.

One bit of information I neglected to mention before was that the CPU window appears shortly after the load, but an F9 sends the application on its merry way, sans breakpoints. There is a screenshot of the disassembly window and callstack when this happens. I also but some shots of the remote system so you could see that the exe, and rsm  are indeed created and the remote debugger is running. The "M:" drive on my development machine is mapped to the Mackenzie folder on the remote machine.

Hope this give you a clue as to what is going on.

Thanks,
Greg
RemoteDebug.zip
I did see one thing that seems like it could be an issue.  On the load process screen it is showing a remote path of

c:\Program Files\Mackenzie\CQueue.exe

Is there such a path on your system?  If I am right Delphi is looking for the program on your system as the process to load, even though it is being generated to the other system.  I would try it as

M:\CQueue.exe.  

Another alternative would be to manually run the application on the remote system and connect to it after it has started.

Sorry that I have not been able to give you a concrete answer to this yet, it has been quite a while since I did remote debugging.  The settings you gave on Load Process make sense... I am just trying to give you some things to try given that what you are seeing is the program that is being run does not match the debug info.  Thats why the bullets disappear.  So you have to ask yourself, where is it getting the program?  You could also try running Process Explorer to check where the exe is being loaded from.  If there is another version available, and that is the one that gets run, then it would explain the dots disappearing.

So, try finding out where it is running from.  If you get no clues from that try running the application on the remote machine separately and then attach to it.  Let me know what you find out.
Avatar of GTDGuy

ASKER

c:\Program Files\Mackenzie\ on the remote system is shared and mapped as "M:" on the host system with Delphi. That is why the paths are not the same but they are pointing to the same place. The load process screen wants the local path of the remote system. The M drive is only use as the target for the EXE and associated files, nothing else. I would think it would be totally out of the picture when the Load Process is invoked.

When I compile, I update a timestamp that shows up on my Logging console in real time. This way I am sure I am running what I think I'm running and its hard coded so I don't get an automatically updated value that would be misleading as well.

    Application.Initialize;
    DefaultLog.Info('Create CQueue Form on 06:20');
    Application.Title := 'CQueue';
    Application.CreateForm(TfrmCMACQueue, frmCMACQueue);

I'll see if I can connect after the application has started.
ASKER CERTIFIED SOLUTION
Avatar of developmentguru
developmentguru
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of GTDGuy

ASKER

I did not ever get back to testing this again. Time constraints made be go to plan "B" and put Delphi an target machine and use RD. However, developmetgurue  was trying hard and gave enough tips that should help others so I'm awarding points to close this item.