Mail Preflet sometimes crashes while switching an account between POP and IMAP

[anevilyak]

With my build of the mail kit using ssl for all the add-ons, I often get a crash when switching the account type. This seems to also correspond to the mode in question not showing any actual config view to set things with. Will try and get more detailed traces for you when I get home.

[bga]

This seems to be a bug with the new OpenSSL version. With the older version, the crash does not happen. It seems some kind of corruption going on as I could see a runtime loader error in my syslog and the stack trace points to an error after a method returns.

Here is what I see in the syslog when the error happens:

KERN: runtime_loader: Could not map image: Invalid Argument KERN: debug_server: Thread 234 entered the debugger: General protection fault KERN: stack trace, current PC 0xaa4038 tf10ConfigView + 0: KERN: (0x7003fcec) 0x38fa49 _FindView7BWindowl + 0x61 KERN: (0x7003fd2c) 0x38a771 DispatchMessage7BWindowP8BMessageP8BHandler + 0x1429 KERN: (0x7003ff1c) 0x38e420 task_looper7BWindow + 0x270 KERN: (0x7003ff7c) 0x2d34b3 _task0_7BLooperPv + 0x3f KERN: (0x7003ffac) 0x4f5b98 thread_entry + 0x20

[bga]

Ops. Now keeping formating.

KERN: runtime_loader: Could not map image: Invalid Argument
KERN: debug_server: Thread 234 entered the debugger: General protection fault
KERN: stack trace, current PC 0xaa4038  __tf10ConfigView + 0:
KERN:   (0x7003fcec)  0x38fa49  _FindView__7BWindowl + 0x61
KERN:   (0x7003fd2c)  0x38a771  DispatchMessage__7BWindowP8BMessageP8BHandler + 0x1429
KERN:   (0x7003ff1c)  0x38e420  task_looper__7BWindow + 0x270
KERN:   (0x7003ff7c)  0x2d34b3  _task0___7BLooperPv + 0x3f
KERN:   (0x7003ffac)  0x4f5b98  thread_entry + 0x20

[bga]

Also, does anyone know who would be the contact at HaikuPorts? I guess they are handling the OpenSSL port now.

[umccullough]

I believe it was Matt Madia that updated the OpenSSL port and I copied it to the optional packages area for him after it got a bit of testing and a patch to change the Jamfiles that referenced the SSL dir (due to the file location change from /boot/home/config to /boot/common to match other shared libraries)

Looks like he documented his process here: ​http://ports.haiku-files.org/wiki/dev-libs/openssl/0.9.8j/2

I'm not sure there's any one person at HaikuPorts that maintains any one port - I get the impression that it's just a dumping ground for port info, including instructions, patches, etc.

They do have a few mailing lists.

[bga]

Maybe it is a good idea to repackage the old version in the correct dir and use it, as this version completelly broke MDR SSL support.

[anevilyak]

It'd probably be best to figure out what's wrong with the new one, part of the reason for updating to 0.9.8j was iirc several security vulnerabilities found in the versions since our original was packaged.

[scottmc]

IIRC one of the problems in building OpenSSL is that they don't have a DESTDIR option for make install, so it drops all it's files into working folders, then you have to go in and figure out which files they were, so it's a bit tricky to build a binary package for this. Perhaps hacking the make file to add support for DESTDIR might clear this up. Perhaps try building it in place using the steps listed on HaikuPorts and see if you still have issues with MDR.

[umccullough]

Ingo created a neat tool called diff_zip that does a good job of only grabbing the files that have changed on an entire subdirectory.

You can add it to your image with UserBuildConfig:

I have it setup at home to add this, and somewhere in the mailing list archives are instructions on how to use it (quite simple).

When I get home tonight, I'll add that to this ticket, and maybe find a place on HaikuPorts to give instructions (unless they're already there).

[mmadia]

First, sorry for the trouble, I currently don't use MDR in Haiku so this wasn't noticed. The configure line I used might have been too aggressive. IIRC correctly, it was : ./config --prefix=/boot/common/ shared no-sse2 zlib-dynamic threads

Replying to bga:

Maybe it is a good idea to repackage the old version in the correct dir and use it, as this version completelly broke MDR SSL support.

If you do repackage the older version, some header files will need to be edited as they contain hardcoded paths. Searching /boot/home/config in the old package should display those hardcoded-paths files.

Replying to scottmc:

IIRC one of the problems in building OpenSSL is that they don't have a DESTDIR option for make install, so it drops all it's files into working folders, then you have to go in and figure out which files they were, so it's a bit tricky to build a binary package for this. Perhaps hacking the make file to add support for DESTDIR might clear this up. Perhaps try building it in place using the steps listed on HaikuPorts and see if you still have issues with MDR.

This isn't totally accurate. Whenever I create pre-complied packages, i re-run configure --prefix=/someCleanPath/common , which then allows me to make, make install, and then archive /someCleanPath/*

[umccullough]

Replying to mmadia:

This isn't totally accurate. Whenever I create pre-complied packages, i re-run configure --prefix=/someCleanPath/common , which then allows me to make, make install, and then archive /someCleanPath/*

I think that's actually a bad practice. I've heard that some packages do code the prefix into the generated content.

[umccullough]

I just remembers that openssl creates symlinks to libs -- i wonder if the process of changing --prefix=<someotherdir> has screwed up the symlinks in this case - can someone check a haiku system with this openssl in /boot/common/lib to see if that's the case?

[mmadia]

Replying to umccullough:

I think that's actually a bad practice. I've heard that some packages do code the prefix into the generated content.

For what it's worth, I distinctly remember editing the hardcoded paths in the header files. Though, I hadn't considered the effect on symlinks or hardcoded paths in object files.

As far no-sse2, I wasn't sure if enabling sse2 would break functionality on non-SSE2 cpus, which is why I used it. The same thinking applied for zlib-dynamic, the documentation said to only use zlib compression if zlib's installed.

Though, I can't remember what the reasoning was for enabling 'threads'

[mmadia]

Seems I forgot to mention a required parameter for 'threads'
./config --prefix=/boot/common/ shared no-sse2 zlib-dynamic threads -D_REENTRANT

[bga]

This has been "fixed" in hrev29320. There is definitely a interaction between loading add-ons linked against OpenSSL and the runtime loader that is triggered only like described here:

​http://www.freelists.org/post/haiku-development/Runtime-loader-problem

Do any of you guys know if OpenSSL registers some object for destruction after unloading (with on_exit_thread() or something similar)?

Anyway, marking as fixed. I will open a different bug about this specific problem.