ID:2872856
 
Resolved
fcopy() crashed when copying a nonexistent file in Linux.
BYOND Version:515.1608
Operating System:Linux
Web Browser:Chrome 112.0.0.0
Applies to:Dream Daemon
Status: Resolved (515.1609)

This issue has been resolved.
Descriptive Problem Summary:
Linux server crashes when doing an fcopy

Numbered Steps to Reproduce Problem:
Run tgstation


Code Snippet (if applicable) to Reproduce Problem:
/// Save file as an external file then md5 it.
/// Used because md5ing files stored in the rsc sometimes gives incorrect md5 results.
/proc/md5asfile(file)
var/static/notch = 0
// its importaint this code can handle md5filepath sleeping instead of hard blocking, if it's converted to use rust_g.
var/filename = "tmp/md5asfile.[world.realtime].[world.timeofday].[world.time].[world.tick_usage].[notch]"
notch = WRAP(notch+1, 0, 2**15)
fcopy(file, filename)
. = md5filepath(filename)
fdel(filename)


Expected Results:
Successful MD5 hash

Actual Results:
DreamDaemon crashes with output:
BUG: Crashing due to an illegal operation!
proc name: md5asfile (/proc/md5asfile)
source file: files.dm,104
usr: (src)
src: null
call stack:
md5asfile(tgui/packages/tgfont/static/tg...)
/datum/asset_cache_item (/datum/asset_cache_item): New("tgfont.eot", tgui/packages/tgfont/static/tg..., null, null)
/datum/asset/simple/namespaced... (/datum/asset/simple/namespaced/tgfont): register()
/datum/asset/simple/namespaced... (/datum/asset/simple/namespaced/tgfont): New()
load asset datum(/datum/asset/simple/namespaced... (/datum/asset/simple/namespaced/tgfont))
Assets (/datum/controller/subsystem/assets): Initialize()
Master (/datum/controller/master): init subsystem(Assets (/datum/controller/subsystem/assets))
Master (/datum/controller/master): Initialize(10, 0, 1)

Backtrace for BYOND 515.1605 on Linux:
Generated at Sat Apr 29 19:30:07 2023

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804b024]
libc.so.6 0x74180, 0x74193 (fileno_unlocked)
linux-gate.so.1 [0xf7f58000, 0xf7f58570], [0xf7f58000, 0xf7f58570]
libc.so.6 0x74180, 0x74193 (fileno_unlocked)
libbyond.so [0xf786e000, 0x0], 0x3466c8
libbyond.so [0xf786e000, 0x0], 0x354dec
libbyond.so [0xf786e000, 0x0], 0x32da8f
libbyond.so [0xf786e000, 0x0], 0x354dec
libbyond.so [0xf786e000, 0x0], 0x373768
libbyond.so [0xf786e000, 0x0], 0x38517c
libbyond.so [0xf786e000, 0x0], 0x32d482
libbyond.so [0xf786e000, 0x0], 0x354dec
libbyond.so [0xf786e000, 0x0], 0x373768
libbyond.so [0xf786e000, 0x0], 0x385bbc
libbyond.so [0xf786e000, 0x0], 0x33670b
libbyond.so [0xf786e000, 0x0], 0x354dec
libbyond.so [0xf786e000, 0x0], 0x373768
libbyond.so [0xf786e000, 0x0], 0x38517c
libbyond.so [0xf786e000, 0x0], 0x32d482
libbyond.so [0xf786e000, 0x0], 0x354dec
libbyond.so [0xf786e000, 0x0], 0x32da8f
libbyond.so [0xf786e000, 0x0], 0x354dec
libbyond.so [0xf786e000, 0x0], 0x373768
libbyond.so [0xf786e000, 0x0], 0x385bbc
libbyond.so [0xf786e000, 0x0], 0x336759
libbyond.so [0xf786e000, 0x0], 0x354dec
libbyond.so [0xf786e000, 0x0], 0x373768
libbyond.so [0xf786e000, 0x0], 0x385bbc
libbyond.so [0xf786e000, 0x0], 0x33670b
libbyond.so [0xf786e000, 0x0], 0x353375
libbyond.so [0xf786e000, 0x0], 0x354790
libbyond.so [0xf786e000, 0x0], 0x30e220
libbyond.so 0x474cb0, 0x474da9
libbyond.so 0x429df0, 0x429ff3
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804bd1c]
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a9c3]
libc.so.6 0x1ade0, 0x1aed5 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a3d1]

Recent proc calls:
/proc/md5asfile
/datum/asset_cache_item/New
/datum/sort_instance/proc/binarySort
/proc/cmp_text_asc
/datum/sort_instance/proc/countRunAndMakeAscending
/datum/sort_instance/proc/timSort
/proc/sortTim
/proc/sort_list
/datum/asset/simple/namespaced/register
/datum/asset/New
/datum/asset/simple/namespaced/tgfont/proc/(init)
/proc/load_asset_datum
/datum/asset_transport/proc/register_asset
/datum/asset_transport/proc/register_asset
/datum/asset_transport/proc/register_asset
/datum/asset_transport/proc/register_asset


Does the problem occur:
Every time, tested multiple

When does the problem NOT occur?
515.1604 and lower, first occurs in 515.1605 through to 515.1608.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
515.1604 and lower

Workarounds:
Unknown
Can you make a test project that shows the problem more succinctly? "Run tgstation" is both too vague and too broad for me to reproduce the issue.
In response to Lummox JR
Yeah, looking for help right now for someone to do that.
In response to Lummox JR
/client/verb/execute_test_code()
set name = "Execute Test Code"

test_code()

/proc/test_code()
var/test_text = "test text"
var/starting_text_file_path = "test.txt"
text2file(test_text, starting_text_file_path)
var/file = file(starting_text_file_path)
var/copied_filename = "test_dir/copied_test_file.txt"
fdel(copied_filename)
fcopy(file, copied_filename)


Was given to me, but I don't have a linux VM to test.
Descriptive Problem Summary:
Trying to use the fcopy proc on a file that does not exist on the system causes Dream Daemon to crash completely. Resulting in a complete server stop.
Numbered Steps to Reproduce Problem:
execute fcopy using a nonexistent file as the first parameter
Code Snippet (if applicable) to Reproduce Problem:
fcopy("garbage.txt", "alsogarbage.txt")


Expected Results:
exception handling for filesystem error
Actual Results:
Hard crash
Does the problem occur:
Every time? Or how often?
every time
In other games?
In other user accounts?
On other computers?

When does the problem NOT occur?
< 515 byond vers.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
did not occur in 514

Workarounds:

I have not found a workaround but other people in /tg/ supposedly have some not very good ones, this issue is of fairly high priority from what I can tell.
Here is a zip file containing the log and code.
https://cdn.discordapp.com/attachments/729771662609743944/ 1114740315304235018/crashtest.zip</515>;
In response to N4K0
This bug does not occur on 1603, notably.
Lummox JR resolved issue with message:
fcopy() crashed when copying a nonexistent file in Linux.