Driver Loading bug in 2.0.9

[stefand]

Hi Dean,
I ran into the following issue:
I wrote a driver that I can compile and run from the Driver development program.
When I try to load it thru the administration program "Add Driver", I get an error that the driver could not be loaded
The remote driver load was not successful.
It says more details in the log, but none are.

Here is the offending code piece:

If (False)
log.trace_message(gvars, sprintf_1("IN %(1)", $CurLine));
EndIf;


If I comment out the log.trace_message line, it loads fine.

This happens in the lastest version 2.0.9
I have made a sample driver that is the smallest piece of code that will demonstrate the problem. (The driver does nothing, it just shows the problem)
Can you investigate?


Edit:

If (False)
log.trace_message(gvars, "hello");
EndIf;

Also causes the error;

Thanks,
Stephan

[Dean Roddey]

It's probably failing to compile, right? What does it say when you try to compile it in the IDE?

[stefand]

It compiles and runs fine in the IDE!

Stephan

[Dean Roddey]

Wierd... OK, I'll check it.

[stefand]

Thanks, Dean

[Dean Roddey]

The problem is that you didn't override one of the initialization methods. For whatever reason the IDE doesn't complain about this so I'll have to check that. But CQCServer checks that you override one of them at least and complains if not.

[stefand]

Ok,
I have delved more into this.

You are right that I forgot to declare the InitializeOther/InitializeSerial and that the CQC Driver Test Harnass did not catch it. However, this was only masking the real problem.

I have attached an even more simple version of the driver that runs fine within the CQC Driver Test harness, but causes an error upon loading in the CQC Admin Interface
domo_qforce,CQCServer,CIDOrbWorkerThread2
(CIDOrb,CIDOrb_ThisFacility.cpp.1495,API Failed-Unknown,6502-0-0)
An unknown exception recieved from server object
LoadDriver

Hope this will help you find the bug
Stephan

[stefand]

Dean, have you had any time to look at this?

[Dean Roddey]

I'll check into it tomorrow.

[Dean Roddey]

That driver loads just fine for me. You don't by an chance have mixed versions of CQC loaded on those machines do you?

[stefand]

Nope, only the lastest.
Can you take the first version and add an InitializeOther function?
I think it will then fail like the second one is doing on my system.
Stephan

[Dean Roddey]

The first one with an InitializeOther loads just fine for me also.

Just as a general aside... You probably don't want to use a Shared directory under the Drivers directory. That could cause problems if people started doing things like that. If it's general purpose stuff, it should probably be either outside of the drivers area altogether, or in some directory that would prevent it from potentially clashing.

[Dean Roddey]

Any more info you can give me on this one? We can turn on some more debugging to see if that gets us any more clues.

[stefand]

Sorry, been away. Will look at this thursday again.
Stefan

[Dean Roddey]

Go ahead and move up to 2.0.12 before you do, just to make sure that you are on the latest and greatest.

[stefand]

Ok,
I guess I need a debugging kernel. I have upgraded to build 13, but I am still running into the problem.
I can run my driver from the development env, but get a failure upon loading from the admin environment.
I cannot find any log files, but I uploaded a snapshot of the log.
Could it be a bug in AppendFmt?
Stefan

[stefand]

This is the method that seems to cause the unknown exception:
Methods=[Public,Final,Const]
Method output_message([InOut]SharedVariables gvars, [In]String Msg)
Begin
Locals=
String prefix_w_time;
Time shorttime;
EndLocals;
If (!gvars.get_debugfile_opened())
Return;
EndIf;
// write this msg to file
shorttime.SetDefFmt("%(H,2,0):%(u,2,0).%(s,2,0)"); // hh:mm.ss
prefix_w_time.AppendFmt(shorttime);
prefix_w_time += output_level_for_next_message + " " + Msg + "\n";
gvars.debugfile_writestr(prefix_w_time);
EndMethod;
EndMethods;

[Dean Roddey]

It's croaking on the AppendFmt call. Can you comment that out temporarily and see if that makes it happy?

[stefand]

No omitting the call does not make it happy,
funny thing is, I took the old driver, and it is also is not happy at loading time any more (used to load fine)
So at this point I don't know what is causing the error.
I can run the driver from the driver developement program, but not load the driver in the administrator program (which I could do in earlier versions of CQC)
Either something has changed in cqc, or in my system environment to make it fail at load time.
No further indication of what is causing the error though.
Stephan

[Dean Roddey]

Export out the classes to text and zip them and the manifest file up and send them to me.

[stefand]

Ok, learned some more.
I moved my driver code to a new subdirectory called "Experimental_Domati" instead of "Domati".
For this I had to edit all my source files and rename the ClassPath to reflect the new path.
Then I tried to compile, and it gave me a weird error message, on the bold piece of code below
Class=[NonFinal]
ClassPath MEng.User.CQC.Drivers.Experimental_Domati.HWConfig uration;
ParentClass MEng.Object;
EndClass;

Imports=
MEng.User.CQC.Drivers.Experimental_Domati.HWItem;
EndImports;

Methods=[Public,Final]

Constructor()
Begin
Locals=
HWItem item;
EndLocals;

item.Instruction(Command.k_Set_TempReport);
It complained that it could not find the class Command.
I then saw that I had not imported the Command class, so I added the following line to the Import section
MEng.User.CQC.Drivers.Experimental_Domati.Command;

After this it compiled without error. Could it be that this was causing the load to fail from the cqc server administration load environement?

Fact is that it is loading fine now .... :confused:

Stephan

[Dean Roddey]

There was an error found right at the very end, too late to do anything about it, where the IDE wouldn't complain necessarily if a classpath is not spelled right. It won't fail until you actually try to instantiate an object of that class and it won't find that class path.

So yes, that could be the issue. I did make one fix on this front in 2.0, but I assume I didn't get it fully fixed somehow. I'll put it back on the list for the next release.

[stefand]

Ok, Dean, I have some more experience with this.

The first time the driver will load ok from the Administrative program.
(Which means it compiles fine)

As I develop code, I compile and run from the IDE and this always works fine.
So then I want to stop the running driver and reload (in order to get the updated code).

This, however, [ from the Admin Program load driver] will sometimes fail on initialization of the driver. It really does not put anything in the log, only that it failed.
From that moment on, there is nothing I can do to make it load.
I have to reboot the cqc server process to be able to load it again.

Is it possible that it was never fully unloaded? Or only partially unloaded (It dissapears from the list of loaded drivers)
When trying to load it for the second or more time, is also when I got the empty com list.
Just some more info as I work with this situation.
Stephan

[Dean Roddey]

Are you sure that the previous driver is successfully unloading? Is there some infinite loop or blocking read that's not completing or something, so that the driver is really stuck and so the new one can't load?

The only reason it would go away from the list is because an exception was thrown out of the initialization. That tells CQCServer that something is fundamentally wrong and it can't even get started, so it just removes it from the list.

[stefand]

No I am not sure the the previous driver unloaded completely and cleanly.
(It would not be from an endless loop or blocking read, but it could have been that I left a file open - now fixed)
Can we tell from the logs whether a driver unload is completely successful, or only partial?

Stefan

[Dean Roddey]

It may be possible for it to get hung after it's removed from the list of drivers. But yeh, if you left a file open, and it's opened in an exclusive mode, trying to open it again the next time might cause the problem.