My code crashes Server: What now?

My code (a work in progress) is repeatedly crashing the server. I am starting up via Terminal so I can see the crash code on the server and Panorama Server is Stopped when viewed from Panorama X Server. I can restart Panorama X Server, but when I run the code again, Server crashes again.

What is the process to find the cause?

I found that you can see the server log output as it updates by opening the server log with BBEdit, but I am not sure if that is the same data that you see in Terminal.

I don’t quite understand what you mean by

The Instrumentation Log can provide a lot more detail and you have numerous favorites that you can select. I had been running Shared Database Basic Operation. There are quite a few favorites that you could try out. I have had so many crashes of PanX, but very few of the server. I am not sure I have ever found the cause of a crash, so good luck.

Are you writing web publishing code that runs on the server? Or are you saying that you are working with a shared database and code you are running on the client is causing the server to crash?

I think you probably mean the latter though that would leave me a bit stumped. When working with a shared database, no code you write ever runs on the server, your code only runs on the client. There are about two dozen simple commands that the client can communicate to the server – open database, close database, synchronize, lock record, unlock record, add record, delete record, etc.

You say that it crashes every time you run “the code”, so that should make it easier to track down. So first of all, please verify that this code is running on the client. Second, what does this code do? Is it simple or something long and complex? If the code is on the client, what does it do when the server crashes? I would assume it would hang waiting for the server to reply? In that case I would add instrumentation to your client code and run it to see how far it gets.

Are you starting the server via Terminal, the client via Terminal, or both?

Like Thomas, I am puzzled by this. Maybe you meant when viewed from the Panorama X Preferences:Server panel? When Panorama X Server is running, it “advertises” its presence on the network via Bonjour. The preference panel checks for this to show whether the server is running or not. If the server quits for any reason (including crashing), it will automatically stop broadcasting it’s presence via Bonjour. So if it does crash, it will indeed show that it is “Stopped” in the preference panel. However, that isn’t really useful diagnostic information.

I am working with a Shared Database and when running a procedure, the Panorama X Server is crashing. Server is being started via Terminal.

I can see in the Terminal window the crash code. Viewing the Server via Screen Sharing, it shows me that the Server has Stopped. Pressing the Start Panorama X Server starts it up again until I run my procedure and it again crashes.

It may be related to my use of the FormulaFill command.

When the Server stops, the Panorama client then can not modify a record as it is not connected to the server.

I am only starting the Server from Terminal, not the Panorama app.

All of my observations that the Server is stopped is via Screen Sharing that has the Panorama X Preferences open with the Server tab selected, showing me that the server is stopped. I press Start Panorama X Server to start it up and all is fine until I run my procedure again.

As it turns out, using FormulaFill with shared databases is the first topic I will be covering in the session tomorrow. Of course I won’t cover why it is crashing for you, because I don’t know the reason, but at least we’ll all be on the same page in regard to how this feature works.

In the meantime, it should be easy to isolate whether FormulaFill is the culprit – try removing that from your code and running the procedure.

The server has special code for FormulaFill that isn’t used for anything else. So it’s definitely possible that there could be a bug that affects only that feature. If that is the case, we’ll need to figure out how your use of FormulaFill is different from how anyone else has used it (and from the various test cases I built for this feature).