ID:82520
 
BYOND Version:454
Operating System:Linux
Web Browser:
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
--THIS EFFECTS VERSION 454 AND BELOW--

This has been an on-going issue with BYOND Linux since I can remember, I've been constantly updating it and it just repeatedly has these issues. It either dies with an error like this, or it sigterm kills itself. (Why the heck would you make the Daemon sigterm itself on an error? Having it crash is much more informative!)
this is irrespective of version.

Wed Sep 23 16:01:04 2009
World closed at 16:01:13 09/23/2009.
Wed Sep 23 16:01:10 2009
Auto-safety mode: safe (working directory access).
World opened on network port 1709.
Welcome BYOND! (4.0 Public Version 447.1028)
World Opened at 16:01:13 09/23/2009.
Server Config file found.
Hostkey Set to Bunnie.
Max Players Set to 500.
BUG: Crashing due to an illegal operation!

Backtrace for BYOND 447.1028 on Linux:
Generated at Wed Sep 23 16:01:15 2009

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a8f8]
libc.so.6 0x71090, 0x710a5 (memcpy)
libc.so.6 [0xb799c000, 0x0], 0x28e20
libc.so.6 0x71090, 0x710a5 (memcpy)
libbyond.so 0x28c5e8, 0x28c627
libbyond.so 0x2ad798, 0x2ad96e
libbyond.so 0x2530bc, 0x25317d
libbyond.so 0x253fe8, 0x25476c
libbyond.so [0xb7c55000, 0x0], 0x1f4471
libbyond.so 0x1f93ac, 0x1f9bc5
libbyond.so 0x23b708, 0x23b769
libbyond.so 0x271304, 0x271413
libbyond.so [0xb7c55000, 0x0], 0x2712cb
libbyond.so 0x273720, 0x273cd0
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049eb7]
libc.so.6 0x15db0, 0x15e8c (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049bc1]

To help the BYOND developers debug this, please send the above trace as part
of a very detailed bug report: http://www.byond.com/members/?command=view_tracker&tracker=1

Backtrace for BYOND 453.1035 on Linux:
Generated at Wed Sep 23 17:32:24 2009

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a8f8]
libc.so.6 0x71090, 0x710a5 (memcpy)
libc.so.6 [0xb79b5000, 0x0], 0x28e20
libc.so.6 0x71090, 0x710a5 (memcpy)
libbyond.so 0x28e620, 0x28e65f
libbyond.so 0x2af7d0, 0x2af9a6
libbyond.so 0x254d88, 0x254e49
libbyond.so 0x255cb4, 0x256438
libbyond.so [0xb7c6e000, 0x0], 0x1f5729
libbyond.so 0x1fa664, 0x1fae7d
libbyond.so 0x23cfcc, 0x23d02d
libbyond.so 0x2730ac, 0x2731bb
libbyond.so [0xb7c6e000, 0x0], 0x273073
libbyond.so 0x275370, 0x275920
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049e77]
libc.so.6 0x15db0, 0x15e8c (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049b81]

To help the BYOND developers debug this, please send the above trace as part
of a very detailed bug report: http://www.byond.com/members/?command=view_tracker&tracker=1
This has now begun to happen each time the server is booted and a player connects to it. I've tried rebooting the machine, clearing the cache, reinstalling BYOND. The works.
As I mentioned in your previous report, "ALL" is not an appropriate value for the version field. Please put in the most recent version you used, and any info on what other versions you have tested can go into the report text itself.

You also still need to edit your other issue to include the proper version number, the most recent one you used at that time.
"ALL" is the appropriate value in this instance. I have tried ALL of the previous versions and ALL are crashing.

You can see the difference in the two of these. But if you really want I'll sit there and get the exact same text for each and every version.
The version field in the bug report is meant to have a specific version number. This is for our reference purposes when we look at a bug later on, such as with your other bug report which is now two months old. Looking at that now, how would I be able to tell what version you were using at the time? That issue is now a candidate for deletion unless you can include the information that you left out the first time.

If you have tested an issue and seen it in more than one version, that information is relevant and it can be included within the report description. The most recent version you have tested at the time of making the report should be the version you put in the "BYOND version" field. I realize based on your report text that you have tested two specific versions in this case, but it is important that the report fields be filled out properly.

On that note it could be relevant which specific version of Linux you are running. In this report you just said "Linux" and in the other you said "ALL Non-Windows" which narrows nothing down, particularly since your other issue may be OS-specific since it didn't show up for us.
is 454 and below accurate enough then? Because this does affect all previous versions and I do not wish to provide false information.
You had it right before the last edit. Just put in 454, not "454 and below". The "and below" stuff can go in the long description like I said.
Lummox JR wrote:
You had it right before the last edit. Just put in 454, not "454 and below". The "and below" stuff can go in the long description like I said.

It is informative enough. I have done the solid testing on all PRIOR versions so what is said there is accurate. So is there some specific (...) reason I cannot leave the current information as-is?
It's an organizational thing. Searching for bug reports on version such and such will skip over your bugs because they're not tagged with proper version numbers. The only reason you should ever use the "Other" in the selection box there is if the actual version number you're using isn't listed.
There you go then. Can we get around to fixing this, rather than having this silly argument over the version number?
Through further testing. I have found the file that has been causing this crashing and a subsequent fix.

hostban.txt inside of .byond/cfg/

If that exists with entries, it causes this crash.
After tracing this back, I found a very minor logic error that could conceivably come into play if the hostban.txt file is malformed. Do you still have a copy of the file that was causing the crash? If so it would help to see that.

At this point it's just a speculation as to whether that is the actual problem, but it seems to make sense. Sadly there's no way to tell what arguments were sent to the functions involved. I'll do some further testing on this using your file and see if I can reproduce the issue on our own Linux server.
The hostban.txt I used was this;
-Link Removed-
That file appears to be blank. Did it upload correctly, or is it actually a blank file?
By using a file that was malformed in the way I discovered, I did manage to provoke a crash in Linux DD 447.1028. The backtrace was not identical, but I don't know if the server might be using a pre-release build of 447 instead of the actual release, or if the bug merely manifested in a slightly different place. A blank hostban.txt file does not provoke this crash. Assuming the file you uploaded did not upload correctly and that it isn't supposed to be blank, I don't have the actual file to verify this with to try to produce identical results.

Because I lack the information to test this further, I'm moving this bug to Unverified status for now pending additional information. The change I made however would have prevented the crash that I did see, so it's possible that this bug actually is fixed for the next version. Unless I can reproduce your crash exactly however, the only way to confirm will be to retest in the next release (456 or up).
I assume something weird must have happened. So I've zipped the file to perhaps keep it as the original document. If not I can provide you with FTP access sometime to download a copy from the server itself. (I backed it up)
http://www.fileden.com/files/2007/5/28/1120183/hostban.zip