Tursiops 0.1 released

Posted on by Chris

As expected, the hacking on Tursiops continued most of last week. I’m a little late getting a release out there, but here it is. The archive contains two folders, one for i386 machines and one for amd64. The copy of Tursiops in each is identical, but the glue library is platform-specific.

If you want the corresponding source code, svn co https://layla.chrishowie.com/svn/Tursiops. This release corresponds to revision 126 if you want the exact code of this release at a later date.

The only known issue at this point is that the “refine search” function does not update the progress meter, and a refine operation cannot be canceled. This should be fixed in the next release.

Feedback is welcome — just comment here. Enjoy!

11 Replies to “Tursiops 0.1 released”

  4. When I run “mono Tursiops.exe” I get this output but the application runs.
    “** (Tursiops.exe:26089): WARNING **: : mprotect failed: Permission denied”

    Clicking “Select Process” spits out this:

    Exception in Gtk# callback delegate
    Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
    System.TypeInitializationException: An exception was thrown by the type initializer for Tursiops.Process —> System.DllNotFoundException: tursiopsglue
    at (wrapper managed-to-native) Tursiops.Process:ptPageSize ()
    at Tursiops.Process..cctor () [0x00000] — End of inner exception stack trace —

    at
    at Tursiops.SelectProcessDialog.RefreshProcesses () [0x00000]
    at Tursiops.SelectProcessDialog..ctor () [0x00000]
    at Tursiops.MainWindow.OnSelectProcessActivated (System.Object sender, System.EventArgs e) [0x00000]
    at GLib.Signal.voidObjectCallback (IntPtr handle, IntPtr gch) [0x00000]
    at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal)
    at GLib.Signal.voidObjectCallback(IntPtr handle, IntPtr gch)
    at GLib.Signal.voidObjectCallback(IntPtr , IntPtr )
    at Gtk.Application.gtk_main()
    at Gtk.Application.gtk_main()
    at Gtk.Application.Run()
    at Tursiops.MainClass.Main(System.String[] args)

  5. @David: Thanks for noting the bug. I’ll work on that for the next release.

    @Daniel: Are you running this from the directory where Tursiops.exe exists? Is there a libtursiopsglue.so in the same folder? Are you in the folder of the right architecture for your system?

  6. daniel@c-f624e655:/mnt/sdb1/tmp/Tursiops-0.1/i386> ls -al
    total 148
    drwxr-xr-x 2 daniel 1000 4096 2007-12-04 04:45 .
    drwxr-xr-x 4 daniel 1000 4096 2007-12-12 11:10 ..
    -rwxr-xr-x 1 daniel users 8687 2007-12-04 04:44 libtursiopsglue.so
    -rwxr-xr-x 1 daniel users 91136 2007-12-04 04:51 Tursiops.exe
    -rw-r–r– 1 daniel users 29045 2007-12-04 04:51 Tursiops.exe.mdb

    daniel@c-f624e655:/mnt/sdb1/tmp/Tursiops-0.1/i386> mono Tursiops.exe

    ** (Tursiops.exe:422): WARNING **: : mprotect failed: Permission denied
    Exception in Gtk# callback delegate
    Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
    System.TypeInitializationException: An exception was thrown by the type initializer for Tursiops.Process —> System.DllNotFoundException: tursiopsglue
    at (wrapper managed-to-native) Tursiops.Process:ptPageSize ()
    at Tursiops.Process..cctor () [0x00000] — End of inner exception stack trace —

    at
    at Tursiops.SelectProcessDialog.RefreshProcesses () [0x00000]
    at Tursiops.SelectProcessDialog..ctor () [0x00000]
    at Tursiops.MainWindow.OnSelectProcessActivated (System.Object sender, System.EventArgs e) [0x00000]
    at GLib.Signal.voidObjectCallback (IntPtr handle, IntPtr gch) [0x00000]
    at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal)
    at GLib.Signal.voidObjectCallback(IntPtr handle, IntPtr gch)
    at GLib.Signal.voidObjectCallback(IntPtr , IntPtr )
    at Gtk.Application.gtk_main()
    at Gtk.Application.gtk_main()
    at Gtk.Application.Run()
    at Tursiops.MainClass.Main(System.String[] args)

    This is on a p4 running opensuse 10.3, mono 1.2.5.

    Tried building libtursiopsglue.so from source (gcc -c -fPIC glue.c -o libtursiopsglue.so) and dropped that in place but that did not change anything. Tried to explicitly path the current dir, tried to rename libtursiopsglue.so to .dll, tried all these things as both user and root. No luck :(.

  7. Also tried dropping libtursiopsglue.so into /usr/lib and rebuilding the linker cachen with ldconfig.

  9. > gcc -c -fPIC -shared glue.c -o glue.o
    > gcc -shared -Wl,-soname,libtursiopsglue.so -o libtursiopsglue.so glue.o
    > cp libtursiopsglue.so ../build/

    > cd ../build/
    > mono Tursiops.exe

    Same problem, it refuses to find the library in the current path. Figured it might be AppArmor being a dick but turning it off made no change. Turned on debug output for mono which spat out some merry 1500 lines or so (http://apache.dataloss.nl/~spidey/debug.log) and the relevant error seems to be:
    DllImport error loading library ‘./libtursiopsglue.so: failed to map segment from shared object: Operation not permitted’.

    Googled a bit for it and it seems to be common with SELinux but that I don’t have. I tried turning off AppArmor (as I figured it has some things in common with SELinux) but that did not resolve anything either. Any ideas? I’m more and more doubting that it’s a bug of yours.

  10. I’d like to see a few other search types, specifically ‘changed’ and ‘unchanged’. Also, it would be nice to be able to dump search results to file, so that I can use this on larger processes. My system doesn’t like it when I find more than 16 million ‘equal to zero’ results….

  11. Huh, I wonder why I didn’t think to use the disk for storage — only every decent Windows trainer does!

    Should be fun to hack that in to the current design.

Comments are closed.