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