Rewriting pup_event in C

What features/apps/bugfixes needed in a future Puppy
Message
Author
User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#31 Post by jemimah »

Dude! You are my new hero. Let me know how I can help you with this project!

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#32 Post by jemimah »

Mounting is working (maybe some issues with ntfs).
EDIT: nevermind about ntfs - it seems fine now.

But unmounting is segfaulting

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x0809e8f3 in ?? ()
(gdb) bt
#0  0x0809e8f3 in ?? ()
#1  0xb78ecac5 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0
#2  0xb7144524 in pup_volume_monitor_generic_cb (conv=0x8220b80, rcvd_data=0x8183f10, is_new=0, user_data=0x0, conv_user_data=0xb5e07598)
    at volume_monitor.c:324
#3  0xb713e3f9 in ps_conv_mgr_sorter_cb (sock=0x812f120, data=0xbffff514, user_data=0x81364c0) at conv.c:156
#4  0xb713be02 in pup_sock_common_marshaller (hook=0x0, marshal_data=0xbffff458) at core.c:250
#5  0xb774d91e in g_hook_list_marshal_check () from /usr/lib/libglib-2.0.so.0
#6  0xb713c22b in pup_sock_raise (sock=0x812f120, event=1, has_data=1, cb_data=0xbffff514) at core.c:240
#7  0xb713cff9 in pup_sock_try_receive_block (sock=0x812f120, timer=0x8183f90, data_read=0xbffff558, error=0xbffff5a8) at transfer.c:262
#8  0xb713d172 in pup_sock_receive (sock=0x812f120, timeout=0, num_blocks=4294967295, error=0xbffff5a8) at transfer.c:296
#9  0xb713d33f in pup_sock_input_callback (sock=0x812f120) at transfer.c:324
#10 0xb713c0e9 in pup_sock_event_source_dispatch (source=0x81467e8, callback=0, data=0x0) at core.c:376
#11 0xb775d2cd in g_main_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0xb775def4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#13 0xb775e0dc in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#14 0xb775e54d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#33 Post by akash_rawal »

jemimah wrote: Mounting is working (maybe some issues with ntfs).
EDIT: nevermind about ntfs - it seems fine now.
If you are getting errors like "Error code 4 (Some other error)", then it is a known problem.

This occurs when drive is mounted, but /proc/mounts is not updated in time.

Do you know how to wait for kernel to update /proc/mounts? inotify doesn't seem to work.
jemimah wrote:

Code: Select all

(gdb) bt 
#0  0x0809e8f3 in ?? () 
It looks like problem of invalid function pointer.

I hope you are testing on Thunar?

I will now download thunar-volman to test it myself now. Thanks for info.

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#34 Post by akash_rawal »

Well I'm unable to get Thunar running on GIO.

After installing thunar-volman from Ubuntu Lucid repository, and now I get this.
Image

How do you get Thunar use GIO instead of hal?

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#35 Post by jemimah »

Thunar-volman is not needed.

Thunar itself can handle mounting/unmounting. You might need a pretty new version of thunar.
Attachments
screenshot.jpg
(43.57 KiB) Downloaded 798 times

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#36 Post by jemimah »

I'm getting these now. I don't think I saw them previously.

Code: Select all

(Thunar:1744): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GMount'

(Thunar:1744): GLib-GIO-CRITICAL **: g_mount_unmount_finish: assertion `G_IS_MOUNT (mount)' failed
Segmentation fault
The unmounting operation actually does complete, by the way.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#37 Post by technosaurus »

PUP_VOLUME_SET_MOUNT is a macro that sets object->mount to mnt by casting mnt as a gpointer ... if gpointer points to a NULL...

could either replace it with a function that checks for null (or mod the macro) or check for null prior to each PUP_VOLUME_SET_MOUNT
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#38 Post by jemimah »

I recompiled Thunar with debug symbols so you could see the complete stack.

Code: Select all

(gdb) bt
#0  0x0809e8f3 in thunar_shortcuts_view_unmount_finish (object=0x8173350, result=0x82791a8, user_data=0x81cc000) at thunar-shortcuts-view.c:1448
#1  0xb78ecac5 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0
#2  0xb7144524 in pup_volume_monitor_generic_cb (conv=0x8220560, rcvd_data=0x8165560, is_new=0, user_data=0x0, conv_user_data=0x82791a8)
    at volume_monitor.c:324
#3  0xb713e3f9 in ps_conv_mgr_sorter_cb (sock=0x812f120, data=0xbffff504, user_data=0x81364c0) at conv.c:156
#4  0xb713be02 in pup_sock_common_marshaller (hook=0x0, marshal_data=0xbffff448) at core.c:250
#5  0xb774d91e in g_hook_list_marshal_check () from /usr/lib/libglib-2.0.so.0
#6  0xb713c22b in pup_sock_raise (sock=0x812f120, event=1, has_data=1, cb_data=0xbffff504) at core.c:240
#7  0xb713cff9 in pup_sock_try_receive_block (sock=0x812f120, timer=0x8161c00, data_read=0xbffff548, error=0xbffff598) at transfer.c:262
#8  0xb713d172 in pup_sock_receive (sock=0x812f120, timeout=0, num_blocks=4294967295, error=0xbffff598) at transfer.c:296
#9  0xb713d33f in pup_sock_input_callback (sock=0x812f120) at transfer.c:324
#10 0xb713c0e9 in pup_sock_event_source_dispatch (source=0x8145c00, callback=0, data=0x0) at core.c:376
#11 0xb775d2cd in g_main_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0xb775def4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#13 0xb775e0dc in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#14 0xb775e54d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#15 0xb7cd3ae9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x08062a76 in main (argc=1, argv=0x822cad0) at main.c:294

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#39 Post by sunburnt »

If I may... a suggestion for your suggestion.

I don`t care for partition icons on the desktop, maybe rewrite HotPup too?

Putting the icons on a slide-out panel would cleanup the desktop.

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#40 Post by akash_rawal »

jemimah wrote: I'm getting these now. I don't think I saw them previously.

Code: Select all

(Thunar:1744): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GMount'

(Thunar:1744): GLib-GIO-CRITICAL **: g_mount_unmount_finish: assertion `G_IS_MOUNT (mount)' failed
Segmentation fault
The unmounting operation actually does complete, by the way.
Thanks, I think I got to the root of the problem.

When a drive is unmounted, the daemon first sends a message that a drive is unmounted so that data is kept up-to-date. In this process the GMount object is destroyed. After that message arrives stating unmount operation has completed, and then thunar tries to access the destroyed object and crashes.

Now the mount function references the object, so that it is destroyed only after message arrives stating unmount operation has completed. Hope this solves the issue. Please test. (See first post)

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#41 Post by jemimah »

No luck. I'm still getting the same error. :(

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#42 Post by akash_rawal »

Well, I had guessed that on reading the corresponding source code of thunar on git.

I downloaded the latest thunar, compiled and ran it myself, and found that it was destroying the mount object after every access. So I modified my module to duplicate the object before starting unmount operation ... and this works!

See first post.

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#43 Post by jemimah »

Perfect! It works with xfdesktop too.

Saluki will have this in the next release and I'll be able to simplify pup_event_frontend_d to only deal with saving and such.

Fantastic!

I am getting error code 4 sometimes when mounting. Can you add a sleep or something somewhere to work around it?

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#44 Post by jemimah »

Something's still a little screwy with unmounting.

If you compile thunar with notification support, you get a notification that the unmount is flushing to disk. But the notification never goes away when the unmount completes.

I can definitely work around this but I think the function call is not returning like it is supposed to.

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#45 Post by akash_rawal »

jemimah wrote: I am getting error code 4 sometimes when mounting. Can you add a sleep or something somewhere to work around it?
I found a workaround.

Although /proc/mounts isn't updated immediately, the mounted drive is accessible as soon as mount exits.

See first post for update. The error code 4 no longer appears for successful mount. (I am relying on mount to exit with non-zero exit code on failure.)
jemimah wrote: If you compile thunar with notification support, you get a notification that the unmount is flushing to disk. But the notification never goes away when the unmount completes.
But I don't get a notification at all.
On unmounting I get this output:

Code: Select all

libnotify-Message: GetServerInformation call failed: The name org.freedesktop.Notifications was not provided by any .service files
libnotify-Message: Error getting spec version

(thunar:14747): libnotify-CRITICAL **: notify_get_server_info: assertion `proxy != NULL' failed

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#46 Post by jemimah »

If you want to see the notifications you also need to install xfce-notifyd.

I ended up compiling thunar without notification support and disabling thunar's error checking. I have the mount script doing all the error checking and user interaction.

It seems to work ok.

I hacked thunar and xfdesktop to set the environment variable so the gio module is only used for those two programs. I got some hangs with other parts of xfce when I set it globally.

Saluki-022 should be out soon and it will have this stuff to play with.

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#47 Post by akash_rawal »

jemimah wrote: If you want to see the notifications you also need to install xfce-notifyd.
Thanks, now I can reproduce your problem.

I recalled that old bug:
jemimah wrote: But unmounting is segfaulting.

Code: Select all

Program received signal SIGSEGV, Segmentation fault. 
0x0809e8f3 in ?? () 
(gdb) bt 
#0  0x0809e8f3 in ?? () 
#1  0xb78ecac5 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0 
#2  0xb7144524 in pup_volume_monitor_generic_cb (conv=0x8220b80, rcvd_data=0x8183f10, is_new=0, user_data=0x0, conv_user_data=0xb5e07598) 
    at volume_monitor.c:324 
#3  0xb713e3f9 in ps_conv_mgr_sorter_cb (sock=0x812f120, data=0xbffff514, user_data=0x81364c0) at conv.c:156 
#4  0xb713be02 in pup_sock_common_marshaller (hook=0x0, marshal_data=0xbffff458) at core.c:250 
#5  0xb774d91e in g_hook_list_marshal_check () from /usr/lib/libglib-2.0.so.0 
#6  0xb713c22b in pup_sock_raise (sock=0x812f120, event=1, has_data=1, cb_data=0xbffff514) at core.c:240 
#7  0xb713cff9 in pup_sock_try_receive_block (sock=0x812f120, timer=0x8183f90, data_read=0xbffff558, error=0xbffff5a8) at transfer.c:262 
#8  0xb713d172 in pup_sock_receive (sock=0x812f120, timeout=0, num_blocks=4294967295, error=0xbffff5a8) at transfer.c:296 
#9  0xb713d33f in pup_sock_input_callback (sock=0x812f120) at transfer.c:324 
#10 0xb713c0e9 in pup_sock_event_source_dispatch (source=0x81467e8, callback=0, data=0x0) at core.c:376 
#11 0xb775d2cd in g_main_dispatch () from /usr/lib/libglib-2.0.so.0 
#12 0xb775def4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 
#13 0xb775e0dc in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 
#14 0xb775e54d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 
akash_rawal wrote: I downloaded the latest thunar, compiled and ran it myself, and found that it was destroying the mount object after every access.
Then this function in thunar opened my eyes.

Code: Select all

void
thunar_notify_unmount_finish (GMount *mount)
{
  NotifyNotification *notification;

  g_return_if_fail (G_IS_MOUNT (mount));

  notification = g_object_get_data (G_OBJECT (mount), "thunar-notification");
  if (notification != NULL)
    {
      notify_notification_close (notification, NULL);
      g_object_set_data (G_OBJECT (mount), "thunar-notification", NULL);
    }
}
Thunar must be assuming a reference on the mount object, else it won't store its data in those objects.

It was a reference counting problem, due to which mount objects were destroyed so often. It is fixed now. See first post.

But we had forgotten the question for which the thread was meant.

Should we handle entire event management in C, including kernel module loading?

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#48 Post by akash_rawal »

I just observed ubuntu lucid setting up my pendrive faster than puppy had ever did.

I am now scanning ubuntu to see what it does. I haven't found anything yet but there are high chances that we'd get something to learn, I believe.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#49 Post by technosaurus »

that is likely because puppy has several sleeps to ensure that older boxes have time to settle and pick up the drive (it also reduce cpu load of the daemon process) - *buntu really doesn't care about them.

if you have a good understanding of the kernel processes that occur when a new device is inserted, its much easier to get a simple solution

from my only basic understanding, I first started by monitoring /sys/block/* ... but further poking around reveals /proc/partitions is also updated for "drives"

a simple shell solution is to do something like

Code: Select all

tail -f /proc/partitions |while read LINE; do
<code here>
done;
in C this could just be equated to fopen /proc/partitions +while fgets line||sleep 1+<code>

the C for looking in /sys/block/*/uevent (the way I do it in shell in jwm_tools) would need dirent, lstat and strtok (to get the = value)

Sorry if this wasn't helpful, i am still writing C as a second language - have to write it shell first and then translate to C
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

akash_rawal
Posts: 229
Joined: Wed 25 Aug 2010, 15:38
Location: ISM Dhanbad, Jharkhand, India

#50 Post by akash_rawal »

technosaurus wrote: that is likely because puppy has several sleeps to ensure that older boxes have time to settle and pick up the drive (it also reduce cpu load of the daemon process) - *buntu really doesn't care about them.
We've got to check whether ubuntu really doesn't care or doesn't need to care.

In most cases it is possible to wait precisely till the device is ready for use. This is usually the fastest solution, as no periodic checks are involved to see whether the device is ready. Also the response is immediate.

Anyways I have very little idea about what to do when a new device is plugged.

e.g. for drives we have to setup corresponding block devices (again, don't know how). After that things are easy: wait for udevd to setup device nodes, use blkid to get partitions and display them on desktop or sidebar, etc.

Post Reply