Menu

#111 parcellite 1.1.7 fails to start on freebsd

Development_Version
closed-fixed
nobody
None
5
2013-12-18
2013-12-17
No

Hello,

The version provided by the FreeBSD ports is really old (1.0.1) and for me doesn't compile. So I've downloaded the archive for the latest (1.1.7) version and was able to successfully compile it, but I receive the following error when starting it:

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_unlock': Operation not permitted. Aborting.

System is:
FreeBSD bessie 10.0-RC2 FreeBSD 10.0-RC2 #0 r259404: Sun Dec 15 08:18:20 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

Attached is the core dump of the app compiled with WITH_DEBUG=yes, using GTK+ 2.24.22. If you require any more information or I can help in any other way to fix this, please let me know.

Regards,
Theo

1 Attachments

Discussion

  • rickyrockrat

    rickyrockrat - 2013-12-17
    • status: open --> closed-invalid
     
  • rickyrockrat

    rickyrockrat - 2013-12-17

    This isn't a parcellite issue.
    Duckduckgo, google, etc:
    http://www.daemonforums.org/showthread.php?t=257
    say they've solved it. There are notes somewhere in the source (Readme?) about building on freebsd. Also, I recommend latest SVN. It is always the most fixed version - there's a bug in upgrading that causes 1.1.7 to segfault.
    See the readme for building from svn. Sorry I'm not more help.

     
    • Theodor Ciobanu

      Theodor Ciobanu - 2013-12-18

      Stack trace is:
      #0 0x000000080346e26a in thr_kill () from /lib/libc.so.7
      #1 0x0000000803535ac9 in abort () from /lib/libc.so.7
      #2 0x000000080255d4c5 in g_thread_abort () from /usr/local/lib/libglib-2.0.so.0
      #3 0x000000080255d4f5 in g_mutex_unlock () from /usr/local/lib/libglib-2.0.so.0
      #4 0x000000000040cf2d in parcellite_init () at main.c:2100
      #5 0x000000000040ce24 in main (argc=1, argv=0x7fffffffda38) at main.c:2294

      According to the docs:
      Calling g_mutex_unlock() on a mutex that is not locked by the current thread leads to undefined behaviour.

      So I added a check before that unlock:

      --- src/main.c.orig 2013-12-17 16:38:05.000000000 +0200
      +++ src/main.c 2013-12-18 15:08:47.000000000 +0200
      @@ -2097,7 +2097,8 @@
      }
      clip_lock= g_mutex_new();
      hist_lock= g_mutex_new();
      - g_mutex_unlock(clip_lock);
      + if (!g_mutex_trylock(clip_lock))
      + g_mutex_unlock(clip_lock);

      show_icon=!get_pref_int32("no_icon");
      / Read history /

      And it seems to be working OK now.

       
  • rickyrockrat

    rickyrockrat - 2013-12-18

    Well, don't I feel like an idiot. That mutex is not even used - it's a bit of code fragment left around from a long time ago. SVN 498 should work for you. My apologies for not looking at the stack trace - I get a lot of system configuration issues that are basically libraries that are incorrectly setup. Thanks for finding & fixing it.

     
  • rickyrockrat

    rickyrockrat - 2013-12-18
    • status: closed-invalid --> closed-fixed
     

Log in to post a comment.