[Pe] segfaults in extensions "{cut, copy} lines"

[ttcoder]

Extensions "Cut Lines Containing" and "Copy Lines Containing" crash when invoked, no matter the use-case scenario. [ticket note: cannot select "Pe" as it's not listed in the Applications drop-down].

[ttcoder]

This started before R1A3, BTW..

Thread 2396 caused an exception: Segment violation
...
(gdb) bt
#0  0x01e178cf in CutContaining ()
   from /boot/apps/Pe/Extensions/Cut Lines Containing
#1  0x181314f8 in ?? ()
#2  0x00000000 in ?? ()
#3  0x00000000 in ?? ()
#4  0x00000009 in ?? ()
#5  0x01e1762a in perform_edit ()
   from /boot/apps/Pe/Extensions/Cut Lines Containing
Previous frame inner to this frame (corrupt stack?)

[anevilyak]

If I'm not mistaken, Pe is maintained at an external repository so tickets should be filed there, but I don't recall which. Assigning to Oliver since he's maintained it in the past.

[zooey]

I've traced the crash in 'Copy Lines Containing' to symbol preemption behaviour when loading the add-on: instead of the regcomp(), regexec() and regfree() symbols from libpcreposix.so (which the add-on links to), the identically named symbols from libroot are used. Since the data type regex_t doesn't match the expecations of the libroot implementation, though, those functions overwrite the stack, which in turn causes the crash.

If Pe is explicitly linked against libpcreposix.so (which it doesn't use, it just uses libpcre.so), the problem can be circumvented, as then the add-on finds the "right" symbols. However, I wonder what the real solution would be? Do we have to mark the reg...() symbols in libroot as weak?

I know scarcely anything about our implementation of symbol preemption, but is it possible that the order in which symbols needed by an add-on is such that the images already loaded with the hosting app are checked before libraries required by the add-on itself?

[axeld]

I'm no expert either, but that's probably why glibc makes everything it exports weak. Ingo would know if the add-on lookup is broken, though. I wonder why this should have any effect on a GCC2 build, though.

[bonefish]

When resolving a symbol all global shared objects (RTLD_GLOBAL) are searched in the order they were loaded. That is also the case when resolving symbols of add-ons. This is probably not quite the way Be intended it to work, but there's really no alternative, if we want to properly support weak symbols.

Regarding the solution to link Pe against libpcreposix.so, that probably causes libpcreposix.so to be in Pe's needed library list before libroot.so so it also ends up early in the global shared object list.

The symbol lookup for gcc 2 (Haiku) and gcc 4 built objects works just the same. The only difference is that gcc 2 built objects are linked symbolically, which means that symbols defined in the object are always used instead of looking them up as well (i.e. symbol preemption is prevented). There's no difference for undefined symbols though.

Normally (i.e. when not hacked like for Haiku) glibc defines "__" prefixed, non-weak versions of all public API functions while the non-prefixed versions are weak. This way the non-prefixed versions can be overwritten while it is still possible to use the original functions internally.

Note that the issue will not really be solved by making libroot's symbols weak, though. Using two libraries that export equally named but incompatible symbols will always remain a problem. E.g. with two add-ons, one using the libroot regex support, the other libpcreposix, one is screwed for sure. The only solution is to load libpcreposix dynamically with RTLD_LOCAL and look up the needed symbols with dlsym().

[zooey]

Fixed in Pe (hrev595 in its central Mercurial repo).