Opened 8 years ago

Closed 7 years ago

#7892 closed bug (fixed)

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

Reported by: ttcoder Owned by: zooey
Priority: normal Milestone: R1
Component: Applications Version: R1/alpha3
Keywords: Pe extension segfault Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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].

Change History (7)

comment:1 Changed 8 years ago by 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?)

comment:2 Changed 8 years ago by anevilyak

Owner: changed from nobody to zooey
Status: newassigned

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.

comment:3 Changed 8 years ago by zooey

Status: assignedin-progress

comment:4 Changed 8 years ago by 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?

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by 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().

comment:7 Changed 7 years ago by zooey

Resolution: fixed
Status: in-progressclosed

Fixed in Pe (revision 595 in its central Mercurial repo).

Version 1, edited 7 years ago by zooey (previous) (next) (diff)
Note: See TracTickets for help on using tickets.