2017-12-01 04:24:31 (edited by ivan_soto 2017-12-01 04:25:43)

Hi everyone,
as you know, I host an online FPS, however the server costs with using a windows server get a little bit on the high end. My question is, does anyone know of a good solution for logging bgt runtime errors and making the program start up automaticly? I'm using auto it with windows, but my financial state does not allow me to be paying $30 a month for a server that servers hosting an FPS and that's it.

Ivan M. Soto.
Feel free to check out my work and services.
http://ims-productions.com

2017-12-02 08:57:34

The answer, as cold as it is, is no. BGT runtime errors appear in graphical windows. You can't log those. At all.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2017-12-02 22:02:07

In the graphical window unless it's a standard library allocation you can press yes to copy the stack trace to the clipboard. I don't know how wine works but I'd think there's be some way of emulating the windows clipboard, so couldn't something be done that way?

2017-12-03 18:03:11

The program actually crashes flat on it's face and exits when the runtime error pops up, because this wine on his servers says something about application tried to create a window and other warnings when you start it. When the runtime window tries to pop up, it ujst flat exits. He might need XServer, since I think it talks about that, but you'd still need to do something strange with I don't even know. As far as I know wine applications cannot interact with each other so we couldn't have the runtime meter intercepting the window. Real shame too, because linux servers give massively awesome pings.

----------
An anomaly in the matrix. An error in existence. A being who cannot get inside the goddamn box! A.K.A. Me.

2017-12-04 01:44:46

@4
You might be able to take advantage of the crash  by having a script that runs in the background checking process information, and relaunches wine when necessary

2017-12-04 13:39:59

Hello,

I just did some searching, I might be able to give a few pointers. These are only ideas, maybe this doesn't work at all, but it is worth trying.
Try intercepting the calls made to the display server with xtrace. You might also need xvfb, I have no idea, completely untested. From what I have red, you can log comunication between the x server and the app by typing:
xtrace myapp
so this may be:
xtrace wine myapp.exe
Hope this helps someone

Roel
golfing in the kitchen

2017-12-08 17:26:25

well we're trying to not just relaunch the program if it crashes, but also to log the runtime error like the windows one currently does so we can see what broke.

----------
An anomaly in the matrix. An error in existence. A being who cannot get inside the goddamn box! A.K.A. Me.

2017-12-08 21:32:14

Yeah, I get that. The runtime error wants to be sent to an x-server, using xtrace might give you the runtime error text if you dig deep enough.

Roel
golfing in the kitchen

2017-12-25 22:13:21 (edited by x0 2017-12-25 22:15:07)

Well, I figured out how to do it. First I installed x  virtual framebuffer to give wine something to send to. Then I launched it and set $DISPLAY to that buffer. Then I just launched my apps and they worked. The runtime meter currently in use is autoit based, looking for the window and doing things to it. The clipboard function to get the call stack appears not to work, so I'm compensating for it by grabbing the text out of the window. The applications don't even all have to be launched by the same virtualized app, they can all interact with each other as long as $DISPLAY is the same between them.
Edit: do note that I am having to use a lengthy command to launch these apps so they can do this.
nohup wine blah.exe &
where nohup makes it not die when you exit and such, and the ampersand makes it run in the background so it won't hold up your terminal.

----------
An anomaly in the matrix. An error in existence. A being who cannot get inside the goddamn box! A.K.A. Me.

2017-12-27 00:46:07

You might want to take a look at gnu screen, it makes it possible to keep terminals alive in the background, that way you don't have to fork to the background. As regards to logging, wouldn't it be easier to enable debug information for the x virtual framebuffer and log that to a file, then periodically read that file checking for strings like runtime error? If you tried something like it and have any insights, that'd be appreciated.

Roel
golfing in the kitchen