Funny how many things we give for granted that are not.
Funny how many things we give for granted that are not.
Everything works as intended now, except for a tiny little detail... ;-)
If I use the host application as loading application to debug the packages, everything works really well.
However, if I select it as main project with debug enabled, I get the following message:
"Host.exe faulted with message: 'system exception (code 0xc0000409) at....'".
If I don't enable debug, instead, it simply crashes and burns without a word.
All packages are runtime and the application is set to use runtime packages. Core is obviously used by the application and I have just one copy of that right now (but I did double check just for extra safety).
Ideas?
Everything works as intended now, except for a tiny little detail... ;-)
If I use the host application as loading application to debug the packages, everything works really well.
However, if I select it as main project with debug enabled, I get the following message:
"Host.exe faulted with message: 'system exception (code 0xc0000409) at....'".
If I don't enable debug, instead, it simply crashes and burns without a word.
All packages are runtime and the application is set to use runtime packages. Core is obviously used by the application and I have just one copy of that right now (but I did double check just for extra safety).
Ideas?
I'm a bit unclear on the scenarios here:
ReplyDelete* EXE
* BPL
If you run the BPL, set to use the EXE to load, all ok.
If you run the EXE, and it loads the BPL, it crashes - where? When loading the BPL? At app startup?
If you run the EXE without debugging, it crashes with no exception dialog - but is probably doing the above.
Is that right? If so, can you write more info about the crash and where and when it occurs, please?
Re checking for multiple modules loaded, have a look at the Modules window, which shows you when each module is loaded and unloaded. You should see a single entry for core.bpl being loaded, and never unloaded until app exit.
That error code is STATUS_STACK_BUFFER_OVERRUN. But yes, it's not at all clear from this post what the exact scenario is.
ReplyDeleteBasically, if I restart, the first time it says it can't find Core.bpl . I am not entirely sure why though. I would have thought that it should.
ReplyDeleteWe don't know what your scenario is. We can only guess. Pretty much every post you make here is vague in this way. Can you be precise.
ReplyDeleteIf I run the application as host of the package, it runs fine. No errors. It loads and works perfectly.
ReplyDeleteHowever: if I run it as main project, it crashes and burns, saying that Core.bpl can't be found, which is an obvious lie since it works beautifully when it's ran as host app for the package.
But we have no idea what any of these modules are doing, how the various parts find each other, and so on. Look at the post. It is devoid of detail.
ReplyDeleteHost: host application
ReplyDeleteCore: package shared by all. As all other packages, it's runtime. No design time bit.
PluginPackage: first plugin package.
PluginPackage2: second plugin package.
Package 1 and 2 are loaded with LoadPackage, which in turn should load Core. Host instead loads Core because it's added to the runtime package list (very few packages because I am most interested in the dynamic).
According to the error message, Core.bpl shouldn't be there, which is a lie.
The crash happens at app startup.
We have no idea where the modules reside with respect to each other, how they are loaded, what code is executed when they are loaded, and so on.
ReplyDeleteHow can anybody else be expected to reproduce this scenario?
And the error message is actually a stack overflow, as I mentioned earlier.
A stack overflow could be something recursive in the loading - "hello BPL", "hello EXE", "oh, wow, hello BPL..."
ReplyDelete(Is personifying code as bright and cheerful chattering figures an indication of madness?)
But as David said, we don't know - can you go into more detail about the loading system and when you see the exception?
SOs are luckily usually pretty easy to fix. All the data you need is in the call stack :)
Host resides in its own directory.
ReplyDeleteThe packages share the BPL, DCP and DCU directories under a "Packages" one that is at the same level with host.
All paths are specified in full.
There is no special code going on, I am sticking to the basics of how this stuff is supposed to be done.
The code to load a plugin is quite simple:
procedure TForm1.LoadPlugin(APluginName: String);
var
PluginHandle: THandle;
PluginCount : Integer;
Plugin : IPlugin;
I: Integer;
begin
PluginHandle := LoadPackage( APluginName );
FHandleList.Add( PluginHandle,APluginName );
if PluginHandle = INVALID_HANDLE_VALUE then
raise Exception.Create('Plugin not found!');
PluginCount := PluginDirectory.PluginCount;
PluginDirectory.Sort;
for I := 0 to PluginCount -1 do
begin
Plugin := PluginDirectory.PlugIn[ I ];
if Not FPluginList.PluginExists( Plugin ) then
begin
FPluginList.Add( Plugin );
end;
end;
end;
David Millington there is basically no call stack. The only thing I can see is ntdll.RtlActivateActivationContextActivateFast .
ReplyDeleteIs Core.bpl loaded during startup or do you load it when needed? Are any units in Core.bpl used by the host application?
ReplyDeleteYes Uwe Raabe, it's loaded at startup by the host and the host does use a unit in the the core package (to make the whole thing work).
ReplyDeleteAre You try on different operating system?
ReplyDeleteAndrea Raimondi In that case the bpl loader uses the dll search algorithm to find the bpl. Try moving core.bpl to the same folder as the exe.
ReplyDeleteIt ought to be simple to make a MCVE and provide it as a gist. Then we wouldn't have to play 20 questions. This happens most times you post here. You'd have the answer by now if you'd done this, and you'd have far more chance of gaining enlightenment since we'd all be really clear as to the problem.
ReplyDeleteDavid Heffernan, the project is, overall, 8 pas files, of which one is not used. It is a bare bones example to get everything working, yet I am finding that it's insanely difficult.
ReplyDeleteYou can see it, we cannot. Good luck with your debugging.
ReplyDeleteAndrea Raimondi If you don't get a call stack, something is corrupted. For stack overflows, they often take time and I've found that it's often possible to toggle back to the IDE and press pause before the actual overflow occurs - then you get a very large call stack.
ReplyDeleteThe other thing to do is to step into the code line by line and see the method calls, and you'll spot what's causing the stack overflow very easily.
If it's 8 files, maybe put them up as a gist? Can you simplify it even further, to just one EXE and package?