File system notification problems

http://crashlog.os4depot.net/?function=view&crashlogid=169

I keep getting the above crash.

I'm using file system notifications in my application to listen to changes on both files and directories. In this case both on RAM:

The crash type above started happening when I changed listening method to not use ADO_DOSMethodOnly.

That is, what I'm talking about is NOTIFYREQUEST/StartNotify() when using ADO_DOSMethodOnly FALSE.

This is on a 4.1 A1 XE install.

Anyone else having such problems?


(The crash log was extracted from serial output, I am unable to store the crashlogs from grim reaper once the crash has occurred.)

@orgin

Not a clue about your crash, but do you know you can dump the memory console if Intuition crashes and everything is frozen. Use command DumpDebugBuffer (the buffer is resident so it survives to soft reset). All crash logs are written there.

@orgin

What method are you using. -> ADO_NotifyMethod
Signal, hook or Message. ??

Show the code for the AllocDosObject() call please.

@colinw

The app has two static notifications and one dynamic. Using two different message ports. One for static ones, the other for the dynamic.

Th static ones are predefined files that are initiated and started at startup and deallocated once the program quits.

The dynamic listens to a directory and changes every time the user selects a new directory.

Dynamic allocations.



Dynamic deallocation.



Static allocation:


static deallocation:

@orgin

Just tested it with ram-handler 53.1 and no problems here,
well, just one, RAM: doesn't support hook method and
doesn't actually fail if that method is used,
it just doesn't call your hook rather than anything
nasty happening.


Just a couple of other comments...

De-queuing any pending messages isn't actually required
when using NRF_SEND_MESSAGE, EndNotify() does it for you.

EndNotify() does nothing when passed NULL, i've adjusted
the autodocs to mention that.

ADO_NotifyName MUST point to a STATIC string buffer that
is valid for the life of the notify request, it is not copied,
it just gets poked into nr_Name. Same goes for Hook structures.

The DOS notify method handles all notification types,
filesystem based notifications are a bit hit-and-miss,
if they are actually supported at all, and if the type
of notifyrequest is actually supported, and if it does
the right thing when supplied with a method it doesn't
understand or support.

Removable device filesystems _may_ also cause issues,
there's no guarantee that they'll do the right thing if a
volume is pulled out with an active notifyrequest.

@colinw

Quote:

Okey, might be this that causes the problem then. I'm changing the path first and after that terminate and change notification to the new path. So I guess the crashes might happen in the short time between.

I'll move the path to it's own storage and change it only once the old notification is terminated.

It's a bit weird that it happens "only" when not using ADO_DOSMethodOnly, but I suppose it might be due to that not using it is quite a lot faster between file system change and the message being sent.

The crash is not entirely easy to reproduce though, sometimes it can run fine for hours, sometimes it happens 30 seconds after reboot. (but always when the notification process is active)

@orgin
"I'll move the path to it's own storage and change it only once the old notification is terminated."


The reason why it probably doesn't cause issues with DOS notifications is likely because I copy the name to its own buffer in the DOS notification handler and use that from then on, I never look at the old pointer after it starts,
this is not done for filesystem packets, so it could likely show up a problem if any of the filesystems happen to peek at the nr_Name at any point during an active request.

It's not likely that this would happen, as the nr_FullName is what's supposed to be used by the handlers, and that is actually copied into its own internal buffer.

However, the docs say to make your name buffer persistent for the life of the request, so it's probably wise, I do know that DOS doesn't access that string after StartNotify() is called, but there are other players here that might not be so forgiving.

I'd still look elsewhere, sounds a bit sus to me....

@colinw

No crashing yet, ohh well, we'll see in a few days. Thanks for the pointers.