Opened 16 years ago
Closed 14 years ago
#3485 closed bug (fixed)
Runtime loader interaction with add-ons and new OpenSSL.
Reported by: | bga | Owned by: | axeld |
---|---|---|---|
Priority: | high | Milestone: | R1 |
Component: | System/runtime_loader | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
It seems that there is an interaction between the new OpenSSL libraries, MDR protocol add-ons and the runtime loader. Here is how it happens:
1 - When you first create an account, it defaults to POP3 as the protocol. If you switch the protocol to IMAP, the preferences panel crashes (more about this below). 2 - If I change the email preferences to default to IMAP as the protocol, it does not crash when switching to POP3 neither when switching back to POP3, but if I save the account as POP3 and close and reopen the preferences panel and try to switch to IMAP, it crashes.
The crash mentioned happens because load_add_on() fails (with a General OS Error) when trying to load the IMAP add-on. Syslog just shows this:
KERN: runtime_loader: Could not map image: Invalid Argument
As seem above, this happens only if POP3 is loaded first (with load_add_on()) and then IMAP is loaded (also with load_add_on()). If the order is reversed, there is no crash. It also only happens with the most recent SSL version (not with the previous version).
The code that fails is this (in runtime_loader/elf.cpp, line 938):
if (image->regions[i].flags & RFLAG_ANON) { image->regions[i].id = _kern_create_area(regionName, (void **)&loadAddress, addressSpecifier, image->regions[i].vmsize, B_NO_ LOCK, B_READ_AREA | B_WRITE_AREA); if (image->regions[i].id < 0) { status = image->regions[i].id; goto error; } image->regions[i].delta = loadAddress - image->regions[i]. vmstart; image->regions[i].vmstart = loadAddress; }
A workaround is to link the program that calls load_add_on() against the OpenSSL libraries so I guess this is related to loading/unloading these libraries but I am not versed on how our runtime loader does that.
Change History (5)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
This is not related to the problem at all. The problem only shows up in very specific circumstances which are not related to paths.
comment:3 by , 14 years ago
Does this still happen? We're a few versions of openssl past where this first happened, maybe it's been fixed in the meantime?
comment:4 by , 14 years ago
Also quite a few things have changed in the runtime loader in the meantime, including a few bug fixes.
comment:5 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I remember vaguely that I saw something similar and that I fixed it in MDR or in the add-ons... Anyway this should be gone or hidden now.
Might there be hard coded path names in MDR? The new OpenSSL moved from /boot/home/config to /boot/common in case it matters.