Crashing..

[bucko219]

Not sure this is a bug, I use TCPSER to run a BBS in Ubuntu 20.04, it connects up fine with Vice. I have noticed though that sometimes it crashes where it completely shuts down, is there a LOG function I could run to send you when it crashes and maybe you can see what is happening when it crashes? The windows version is pretty solid, I have it now running for well over 100 calls without crashing, but my Linux one crashes sometimes after 10 calls or as high as 50 calls.. Any info would be appreciated..

[geneb]

On Tue, 31 Aug 2021, bucko219 wrote:

Not sure this is a bug, I use TCPSER to run a BBS in Ubuntu 20.04, it connects up fine with Vice. I have noticed though that sometimes it crashes where it completely shuts down, is there a LOG function I could run to send you when it crashes and maybe you can see what is happening when it crashes? The windows version is pretty solid, I have it now running for well over 100 calls without crashing, but my Linux one crashes sometimes after 10 calls or as high as 50 calls.. Any info would be appreciated..

I haven't used tcpser in quite a while, but I seem to recall various logging levels that you can set up - try "tcpser --help" or "tcpser -?" to get it to spit out the command line options.

g.

[bucko219]

Thanks for the response Gene, I use a -l 4 which gives a good amount of info, problem is it doesn't save to disk. Is there a command to save to disk??

[geneb]

On Wed, 1 Sep 2021, bucko219 wrote:

Thanks for the response Gene, I use a -l 4 which gives a good amount of info, problem is it doesn't save to disk. Is there a command to save to disk??

You can do this:

tcpser [parameters] >>logfile.txt 2>&1

This will open logfile.txt for append and redirect both stderr and stdout to the file.

g.

[rickard-von-essen]

Rebuild with debug symbols (check the gcc man page for the correct flag).

Run under gdb. When it crashes examine the stacktrace.

[bucko219]

Thanks for the info guys, I will give it a try and see what happens.. Thanks again..

[go4retro]

For the OP: -L is the way to redirect to a file.

[jayctheriot]

tcpser -l <loglevel 1-7> -L </path/to/log/filename>

I would "touch" the log file prior to running the above command. That way, it insures that you have the ability to write to it. However, be aware that if you "touch" as root, you will have to set the appropriate permissions to write to the file.

[bucko219]

Just a quick followup, the logs revealed nothing other then TCPSER just dying, there was a connection from an outside IP address, and TCPSER shut down. There are no error messages. So that leads me to when I build it I get the following error: src/ip232.c: In function 'ip232_set_control_lines': src/ip232.c:119:7: warning: ignoring return value of 'write'. declared with attribute warn_unused_result [-Wunused-result] 119| write( cfg->fd, cmd, sizeof(cmd)):

No other errors it compiles and runs, just dies at random times. I am running Ubuntu 20.04 latest updates using it to connect to VICE Emulator. Everything works fine, except for the shutdown that comes at different times.

Any ideas??

[go4retro]

Are you using the master branch or the "VICE kudge" branch? Try the other one to see if the problem persists.

Jim

[rickard-von-essen]

To run it in gdb do:

1) edit the Makefile and change to:

CFLAGS = -O $(DEF) -Wall -ggdb

2) Rebuild make clean; make 3) Verify that you now have debug symbols file tcpser, should say with debug_info, not stripped 4) Start it in gdb by executing gdb tcpser 5) Start tcpser with the same flags you normally use with run <flags> 6) Wait for it to crash and provide the info here. After it crashed use the command backtrace in gdb.

[bucko219]

Jim, I am using the master branch (That Kludge issue was fixed). When I was running the Kludge I had the same issues, for some reason it would just die randomly.. Rickard, I will do as you say. Thanks, I will post back soon...

[bucko219]

Welp here is what I have...

Thread 2 "tcpser" received signal SIGPIPE, Broken pipe. [Switching to Thread 0x7ffff7d94700 (LWP 91405)] __libc_write (nbytes=10, buf=0x5555555604a8 , fd=20) at ../sysdeps/unix/sysv/linux/write.c:26 26 ../sysdeps/unix/sysv/linux/write.c: No such file or directory.

Does that help at all?

[bucko219]

Just happened again tonight, same info as above.. :)

[go4retro]

I just got back from VCF-MW in Chicago, so it's going to take me a few days to recover. It looks like a MDM_NO_ANSWER write is causing the issue, and that only happens in 1 place, and the code travels all the way to ip_write:192. I would put some debug there (wrap the write in some code that checks the validity of the file descriptor in df ala https://stackoverflow.com/questions/12340695/how-to-check-if-a-given-file-descriptor-stored-in-a-variable-is-still-valid)

If the fd is invalid, do a ELOG(LOG_ERROR,"File descriptor is no longer valid");

The fact that the fd is gone should not cause a SIGPIPE, I don't think, but perhaps the above will stop the symptom so we can track it down from the logs.

[bucko219]

I'm sorry Jim, you lost me at VCF-MW.. I assume this is being done in TCPSER?? I can Assemble the code, but when it comes to writing it I am clueless.. When you are free if you can give me some help that would be great.. No rush.. :)

[bucko219]

Just a quick update and to close this issue, I am 99% sure my issue is solved. I have switched from Debian based to Manjaro (not sure if this solved it or not) and then re-downloaded TCPSER and did a make clean then a make in TCPSER, I haven't had a crash in just about 2 weeks. I couldn't go a day before. I also made some config changes in Vice going from Swiftlink to Turbo232 I doubt that is the answer but I am not changing it.. So I am closing this..

[bucko219]

Closed..