Girder 3.3.8 Crashing on LDJ Rescan.

[danward79]

Hi,

Eversince I upgraded to Girder 3.3.8 on my Server, it has been crashing everytime I do a LDJ Rescan, from NR.

I get the attached error msg.

I tried running Debugview and get no outout. I also tried NTFileMonitor. I attach the output.

Anyone got any ideas?

[danward79]

Found the answer, with the assitance of Rob

Turned out to be the directory watcher of winluaex

[Mark F]

What did it do? :roll:

[Rob H]

Created 4 folderwatchers and then killed girder on the 5th

Incidentally, it also kills girder if the directory you're trying to watch doesn't exist.

[Mark F]

The folder watchers seem to be more trouble than they are worth. :(

The are filesystem contructs and don't work the same from system to system. What a pain. :evil:

(just venting)

[Rob H]

It'd be nice if WinLuaEx trapped the exception though.

[danward79]

Hi, Sorry, Missed all this been at work! :cry:

Thanks for passing on the info Rob, Cheers for noting it Mark. :D

That was easy, just wait for a fix now!

:wink:

[Mark F]

You don't get off that easily. ;)

I cannot "fix" this. That is, I cannot make this work in every situation because this happens when some Windows or network resource is exhausted. The question becomes, "What should WinLUAEx do when it detects a problem while creating a folder watcher object?" Should it:

Do nothing (grash Girder; current behavior) :D
Cause a LUA error (end the current script)
Cause a popup
Return nil
Log an error message to the Logger window
Some combination of the above
Something else


If I get no responses, I'll return nil and log an error message.

[Rob H]

I'd suggest returning nil and and an error message, and maybe logging the error message as well.

[danward79]

I'd suggest returning nil and and an error message, and maybe logging the error message as well.

I am with Rob, sounds like a good compromise

[Mark F]

That is why #6 and #7 were on the list. :)

[Mark F]

Here is a .ZIP of the beta of the discussed changes. Let me know if this is OK and I'll release it.

[Rob H]

That is why #6 and #7 were on the list. :) :lol: :lol: :lol:

[Rob H]

Here is a .ZIP of the beta of the discussed changes. Let me know if this is OK and I'll release it.

That looks pretty good - an explanation of the error in the returned error message would be good. Also the logged message has two unprintable characters at the end, which looks odd - I'm guessing a CRLF?

Otherwise it works fine.

If I can make a suggestion, could we have a numeric error code, at least as the first word of the error message? A text string may cause problems if it's the error explanation, any error handling would get screwed by international versions of Windows.

[Mark F]

Here is a .ZIP of the beta of the discussed changes. Let me know if this is OK and I'll release it.

That looks pretty good - an explanation of the error in the returned error message would be good. Also the logged message has two unprintable characters at the end, which looks odd - I'm guessing a CRLF?

The LFCR at the end of that statement is added by the Win32 interface I use to format the message. See the FormatMessage() documentation (if you care). The point is I can't change it. :(



Otherwise it works fine.

Yet the next paragraph exists... :D :lol:



If I can make a suggestion, could we have a numeric error code, at least as the first word of the error message? A text string may cause problems if it's the error explanation, any error handling would get screwed by international versions of Windows.
Great idea. I hadn't thought of that.

What if I do 2 things:
1) Add the error code at the begining of the returned string (prepend -"Error %d:" on the string instead of "Error:"; %d will be the value returned from the GetLastError() Win32 API)
2) Concatenate the two logged strings (with a LFCR "\r\n" between them) and return that

With these two additions, the returned string can be parsed into pieces using "\r\n". The first string will contain the error code number that can be extracted, as needed, by pattern matching. The second string will be the cause in the current language.

This is called "Beta 2". :)

[Rob H]

That's perfect.

But...









Just kidding :)

[Mark F]

Unfortunately, this version fails pretty badly on my slow Windows '98 machine at home. I have some more work to do. :(

The interface will remain as we have worked out. The stuff "behind the curtain" will change.

[Mark F]

I have released this to the SourceForge.net site. Normally, Mike C wraps an installer around it and places that on this site. If you want it before then, :) here are the SourceForge links:

Executable and documentation .zip file (http://prdownloads.sourceforge.net/girderplugins/WinLUAEx.1.0.12.2.zip?download)

Source code .zip file (http://prdownloads.sourceforge.net/girderplugins/WinLUAEx.1.0.12.2.src.zip?download)

[danward79]

Thanks Mark