osmo crashed with SIGSEGV in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()

Bug #1297872 reported by Cliff Carson
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Pipelight
New
Undecided
Unassigned
osmo (Ubuntu)
New
Medium
Unassigned

Bug Description

This bug report is trying to document a problem between Osmo and Pipelight.

After installation of Pipeline starting Osmo will result in an invalid window generated by gtk. The window is full screen, missing the banner line, and many components in the window generated incorrectly. The config.xml file is filled with invalid data causing the next start of Osmo to crash or allocate large chunks of memory. Removing Pipelight allows Osmo to function normally.

Updating a previously saved Note and got this error after saving then using the Quit button.

The Osmo window was "stuck" in maximized mode. Could not figure out how to get it into window mode. May not be an Osmo problem because the shortcut keys for maximize/minimize (alt-F9/alt-F10 or alt-F5)don't seem to work on any window.

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: osmo 0.2.10+svn937-1
ProcVersionSignature: Ubuntu 3.13.0-16.36-generic 3.13.5
Uname: Linux 3.13.0-16-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Mar 26 09:58:00 2014
ExecutablePath: /usr/bin/osmo
InstallationDate: Installed on 2014-02-13 (40 days ago)
InstallationMedia: Ubuntu-GNOME 14.04 "Trusty Tahr" - Alpha amd64 (20140211)
ProcCmdline: osmo
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SegvAnalysis:
 Segfault happened at: 0x7f341238a64d: lock xadd %edx,(%rax)
 PC (0x7f341238a64d) ok
 source "%edx" ok
 destination "(%rax)" (0xfffffffffffffff8) not located in a known VMA region (needed writable region)!
SegvReason: writing unknown VMA
Signal: 11
SourcePackage: osmo
StacktraceTop:
 ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 PluginConfig::~PluginConfig() () from /usr/lib/pipelight/libpipelight-silverlight5.1.so
 __run_exit_handlers (status=0, listp=0x7f341aa476c8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
 __GI_exit (status=<optimized out>) at exit.c:104
Title: osmo crashed with SIGSEGV in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

Revision history for this message
Cliff Carson (ccarson1) wrote :
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 __exchange_and_add (__val=-1, __mem=0xfffffffffffffff8) at /build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/ext/atomicity.h:49
 __exchange_and_add_dispatch (__val=-1, __mem=0xfffffffffffffff8) at /build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/ext/atomicity.h:82
 std::string::_Rep::_M_dispose (this=0xffffffffffffffe8, __a=...) at /build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:246
 _M_dispose (__a=..., this=<optimized out>) at /build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:538
 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=<optimized out>, __in_chrg=<optimized out>) at /build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:539

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceSource.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in osmo (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Revision history for this message
Cliff Carson (ccarson1) wrote :

Since this error occurred Osmo no longer comes up. Get a white full screen and after a minute or so it closes. No messages or error indications.

Revision history for this message
Cliff Carson (ccarson1) wrote :

Found this entry in the kern.log after trying to start Osmo.

traps: osmo[4101] trap int3 ip:7f9ad8fb6c13 sp:7fffe7026770 error:0

Revision history for this message
Cliff Carson (ccarson1) wrote :

Starting osmo from command get the following message, appears to have some interaction with Pipelight which is installed on this system. The Osmo window did come up but in maxmized mode but missing the Osmo banner line on top.

cliff@cliffps:~$ osmo
[PIPELIGHT:LIN:unknown] attached to process.
[PIPELIGHT:LIN:unknown] checking environment variable PIPELIGHT_SILVERLIGHT5_1_CONFIG.
[PIPELIGHT:LIN:unknown] searching for config file pipelight-silverlight5.1.
[PIPELIGHT:LIN:unknown] trying to load config file from '/home/cliff/.config/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] trying to load config file from '/etc/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] trying to load config file from '/usr/share/pipelight/configs/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] sandbox not found or not installed!
[PIPELIGHT:LIN:silverlight5.1] GPU driver check - Your driver is supported, hardware acceleration enabled.
[PIPELIGHT:LIN:silverlight5.1] using wine prefix directory /home/cliff/.wine-pipelight/.
[PIPELIGHT:LIN:silverlight5.1] checking plugin installation - this might take some time.
[install-dependency] wine-silverlight5.1-installer is already installed in '/home/cliff/.wine-pipelight/'.
[install-dependency] wine-mpg2splt-installer is already installed in '/home/cliff/.wine-pipelight/'.
[install-dependency] wine-wininet-installer is already installed in '/home/cliff/.wine-pipelight/'.
[PIPELIGHT:WIN:silverlight5.1] embedded mode is on.
[PIPELIGHT:WIN:silverlight5.1] windowless mode is off.
[PIPELIGHT:WIN:silverlight5.1] linux windowless mode is off.
[PIPELIGHT:WIN:silverlight5.1] force SetWindow is off.
[PIPELIGHT:WIN:silverlight5.1] unity hacks is off.
[PIPELIGHT:WIN:silverlight5.1] window class hook is on.
[PIPELIGHT:WIN:silverlight5.1] replaced API function CreateWindowExA.
[PIPELIGHT:WIN:silverlight5.1] replaced API function CreateWindowExW.
[PIPELIGHT:WIN:silverlight5.1] replaced API function TrackPopupMenuEx.
[PIPELIGHT:WIN:silverlight5.1] replaced API function TrackPopupMenu.
fixme:advapi:RegisterTraceGuidsW (0x2b1f87, 0x350118, {aa087e0e-0b35-4e28-8f3a-440c3f51eef1}, 1, 0x68f6a8, (null), (null), 0x350118): stub
[PIPELIGHT:WIN:silverlight5.1] init successful!
[PIPELIGHT:LIN:silverlight5.1] using thread asynccall event handling.
[PIPELIGHT:LIN:silverlight5.1] using thread asynccall event handling.
output error : string is not in UTF-8
output error : string is not in UTF-8
Segmentation fault (core dumped)
cliff@cliffps:~$ fixme:advapi:UnregisterTraceGuids 0: stub

Downloaded Osmo 0.2.10 from the Osmo web site, complied/linked and it appears to run OK, no interaction with Pipelight. Only problem I saw was that the Contacts tab was missing.

Revision history for this message
Cliff Carson (ccarson1) wrote :

I'm in way over my programming head but believe the above crash is because the osmo config.xml file is getting written with invalid information. The cause of the above crash is when gtk tried to allocate a huge window size because the <window_size_x>
and <window_size_y> had huge numbers. Suspect that the libxml is at the wrong level for osmo (just a guess). I know for a fact that the source level of osmo (0.2.10) will compile and works but is missing Contact because libgtkhtml is at the wrong level. The source is expecting libgtkhtml-2.0 and the current level on Trusty is libgtkhtml-4.0.

Revision history for this message
Cliff Carson (ccarson1) wrote :

The problem with the Osmo package distributed on Trusty is some interaction with the Pipelight package. Starting Osmo from the command line with an empty configuration directory results in the Pipelight output (see post 8) and an invalid window (fullscreen with tabs inconsistant). Closing the window the Segmentation fault occurs and checking the config.xml file you find many fields with invalid data.

Downloaded the 0.2.10 Osmo package and compilied it on this system and the above problem does not occur. The compilied Osmo is missing the Contacts function because it is expecting libgtkhtml-2.0 and Trusty has libgtkhtml-4.0, all the other functions (Notes, Calendar, and Task) work fine.

Revision history for this message
Cliff Carson (ccarson1) wrote :

Ran a test on my working Trusty level desktop. Both the 14.04 distribution level and the 0.2.10 compiled level of Osmo worked on this desktop. I installed Pipelight and got Netflix working. From an command line started the distribution level of Osmo and saw the odd references to functions of Pipelight running (see comment #8). The Osmo window appeared and was fullscreen and had the same invalid tabs/components. On termination got a segmentation falt. Next tried the compiled Osmo (compilied prior to installing Pipelight) and it worked without problems. Removing Pipelight and both versions of Osmo worked. I'm at a stop in this process since I don't have access to how the 14.04 module was built.

Cliff Carson (ccarson1)
description: updated
Cliff Carson (ccarson1)
description: updated
Revision history for this message
Cliff Carson (ccarson1) wrote :

Some progress...now have a compiled level of 0.2.12 of Osmo (this is the distribution level that is failing). When running this level I do not get the faulure of the fullscreen/invalid window but still see the strange calls to the Pipelight code (see comment #8). Executing the distribution level of code still fails as before. Will now try to set dbg on to see if I can find out where the Pipelight code is called. Believe now that when running the distribution level of code a work area for the screen configuration is being stepped on.

Revision history for this message
Cliff Carson (ccarson1) wrote :

Got a debug version of Osmo running and found that the addition of Webkit to Osmo is doing a call to webkit_web_view_new() which when Pipelight is installed passes control to a plugin that is executing Pipelight code. In the case of the debug version no external problem is seen (except some delay in starting the first screen). In the case of the distribution level of Osmo I think a configuration area is being overlayed causing the bad screen and the Segmentation failure. Here is the debug output when stepping through calendar.c.

2359 appGUI->cal->html_webkitview = WEBKIT_WEB_VIEW (webkit_web_view_new ());
(gdb) next
[PIPELIGHT:LIN:unknown] attached to process.
[PIPELIGHT:LIN:unknown] checking environment variable PIPELIGHT_SILVERLIGHT5_1_CONFIG.
[PIPELIGHT:LIN:unknown] searching for config file pipelight-silverlight5.1.
[PIPELIGHT:LIN:unknown] trying to load config file from '/home/cliff/.config/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] trying to load config file from '/etc/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] trying to load config file from '/usr/share/pipelight/configs/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] sandbox not found or not installed!
[PIPELIGHT:LIN:silverlight5.1] GPU driver check - Your driver is supported, hardware acceleration enabled.
[PIPELIGHT:LIN:silverlight5.1] using wine prefix directory /home/cliff/.wine-pipelight.
[PIPELIGHT:LIN:silverlight5.1] checking plugin installation - this might take some time.
[install-dependency] wine-silverlight5.1-installer is already installed in '/home/cliff/.wine-pipelight'.
[install-dependency] wine-mpg2splt-installer is already installed in '/home/cliff/.wine-pipelight'.
[install-dependency] wine-wininet-installer is already installed in '/home/cliff/.wine-pipelight'.
[PIPELIGHT:WIN:silverlight5.1] embedded mode is on.
[PIPELIGHT:WIN:silverlight5.1] windowless mode is off.
[PIPELIGHT:WIN:silverlight5.1] linux windowless mode is off.
[PIPELIGHT:WIN:silverlight5.1] force SetWindow is off.
[PIPELIGHT:WIN:silverlight5.1] unity hacks is off.
[PIPELIGHT:WIN:silverlight5.1] window class hook is on.
[PIPELIGHT:WIN:silverlight5.1] replaced API function CreateWindowExA.
[PIPELIGHT:WIN:silverlight5.1] replaced API function CreateWindowExW.
[PIPELIGHT:WIN:silverlight5.1] replaced API function TrackPopupMenuEx.
[PIPELIGHT:WIN:silverlight5.1] replaced API function TrackPopupMenu.
fixme:advapi:RegisterTraceGuidsW (0x2b22a7, 0x350120, {aa087e0e-0b35-4e28-8f3a-440c3f51eef1}, 1, 0x68f6a8, (null), (null), 0x350120): stub
[PIPELIGHT:WIN:silverlight5.1] init successful!
[PIPELIGHT:LIN:silverlight5.1] using thread asynccall event handling.
[PIPELIGHT:LIN:silverlight5.1] using thread asynccall event handling.
2360 webkit_web_view_set_settings (appGUI->cal->html_webkitview, appGUI->cal->webkit_settings);
(gdb)

Revision history for this message
Cliff Carson (ccarson1) wrote :

Done with this problem. Have compilied Osmo 0.2.12 with the latest libwebkitgtk-1.0-0 and replaced the 14.04 distribution Osmo. Still don't understand the reasons for the call to the pipelight code. Recomment that Osmo 0.2.12 be re-distributed after recompiling with latest level of libwebkitgtk-1.0-0.

Cliff Carson (ccarson1)
information type: Private → Public
Revision history for this message
Sebastian Lackner (slackner) wrote :

Hi Cliff,

Based on the Stacktrace the crash itself seems to be in Pipelight code, but its not immediately clear if this is a problem with libwebkitgtk / Osmo or Pipelight itself. It would probably be helpful to take a look at some more detailed debug output.

Can you probably compile Pipelight yourself with --debug enabled and attach a new log from the terminal output?
I assume that you already have some experience with compiling software, if not we can also provide some more detailed instructions.

I would suggest to checkout Pipelight from git:
https://bitbucket.org/mmueller2012/pipelight/overview

Afterwards you have to modify debian/rules and add " --debug" at the end of line 7 and 9:
https://bitbucket.org/mmueller2012/pipelight/src/5d5e122ee51d11e1d1ccf9a37c50fdc0e7b94704/debian/rules?at=master#cl-7

The required build dependencies are:

Build-Depends: debhelper (>= 8), libc6-dev(>= 2.11.1), libx11-dev (>= 2:1.3),
 mingw-w64, g++-mingw-w64, make (>= 3.81), g++ (>= 4:4.4), sed (>= 4.2.1), po-debconf

Then just build the package (for example with "debuild -uc -us -b") and install it.

Please try to reproduce the problem, and then attach a new log containing all stderr & stdout output, for example with:

osmo &> pipelight.log

It should contain a lot more detailed output including all function calls which are relayed by Pipelight. Please attach the log to this bug report.

Regards,
Sebastian

Revision history for this message
Cliff Carson (ccarson1) wrote :

HI Sebastian,
as I said in this bug report I believe the problem is that the 14.04 distribution of Osmo was compiled under a different level of webkit causing the problem when installing Pipelight and a new level of webkit. Now that I have the latest level of webkit installed and have compiled Osmo under that level I no longer have a problem (except the call to the Pipelight functions under Osmo). Received some text from Michael about disabling plugins in webkit which I suspect should correct that problem. Appending Michael's text to this bug to inform the Osmo owners.

Cliff

Hi,

the reason why Pipelight gets active is that Webkit loads all plugins to enumerate which kind of mimetypes are supported (i.e. Flash videos, Silverlight applications, ...). I don't know exactly what goes wrong in your case, but I would suggest Osmo to simply disable plugins in Webkit if they do not need them. From a security point of view they should definitely disable them, otherwise it may be for example possible to embed a malicious flash video into a note.

I am not very familiar with using webkit as library, but i think they will need to set this setting to false:
http://webkitgtk.org/reference/webkitgtk/stable/WebKitWebSettings.html#WebKitWebSettings--enable-plugins

Other programs like for example Liferea (a RSS reader) allow to disable / enable browser plugins in their settings and they also use Webkit.

Most browsers start plugins in a separate process to avoid crashing the main process. It may therefore be possible that we have some bug inside our code which will only occurs if the plugin is loaded into the main process, but looking through the source code I was not able to find anything which could cause such a problem.

Michael

Revision history for this message
Cliff Carson (ccarson1) wrote :

Looking into the recommendation by Micheal to set enable-plugins FALSE to stop the Pipelight code from being executed. The calendar.c line of code that resulted in the execution of the Pipelight code is the call to WebKit to set enable-scripts and enable-plugins to FALSE. The call to WebKit appears to be correct per the webkitgtk.prg web site. Questions I need help with..

1 - am I reading the db output right (see comment #13) that this instruction resulted in the execution of the Pipelight code? There are several threads running
2 - What is the pipelight attached process, is it a plugin?
3 - What additional debug information should I gather and how do I do it (reached my limit on my knowledge on running debug).

Revision history for this message
Cliff Carson (ccarson1) wrote :

Unsure of what I was seeing using dbg just added printf statements before and after the call to webkit_web_view_new() (calendar.c line 2359) and sure enough the Pipelight output was between those printf statements. Looking at that routine in libwebkit-1.0 it does nothing but create a NULL WEBKIT_WEB_VIEW object in a single line of code with a call to g_object_new().

Revision history for this message
Cliff Carson (ccarson1) wrote :

Install the distribution level of Gnome 14.04. Tested successfully tested osmo, no failures noted. Installed Pipelight and re-tested osmo and got the same segmentation fault with the Pipelight process (see comment #8) showing up in the command window. Removed the distribution level of osmo (0.2.12) and install my compilied level of 0.2.12. Testing this level still get the Pipelight process output in the command window but osmo appears to run OK.

Revision history for this message
Cliff Carson (ccarson1) wrote :

Adding debug backtrace to further document that Osmo is entering Pipelight code (believe basicplugin.c). Osmo GUI is at this point trying to setup to disable plugins but has not completed that call yet. The breakpoint was set to stop on entry to attach() in basicplugin.

Revision history for this message
Cliff Carson (ccarson1) wrote :

Just installed final beta of gnome 14.10 and did the following test.

- install osmo
- tested osmo (every thing OK)
- installed pipelight
- ran netflix (ran OK)
- re-tested osmo, did not run correctly, failed as described above
- copied my recompiled level of osmo and retested (ran OK)

My conclusion is that the distribution level of osmo must be recompiled with the latest level of libwebkitgtk.

Revision history for this message
Cliff Carson (ccarson1) wrote :

Now that Google Chrome supports Netflix I have remove Pipelight. Now both the distribution level of Osmo and my re-compiled version work with out errors.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.