byond crashes when calling old style call_ext dlls

ID:2880096
 
Jul 18 2023, 10:52 pm
Resolved
call_ext() with older-style string-only calls was passing null pointers to the external library in some cases instead of blank strings, which caused problems for libraries that expected non-blank strings.
BYOND Version:515.1609.final
Operating System:server2012r2
Web Browser:Chrome 109.0.0.0
Applies to:Dream Daemon
Status: Resolved (515.1610)
This issue has been resolved.
Descriptive Problem Summary:
515.1609 release crashes when calling string style dlls using call_ext
Jul 18 2023, 10:57 pm (Edited on Jul 18 2023, 11:21 pm)
dd.log on CMSS13:

Tue Jul 18 21:55:24 2023
World opened on network port 1400.
Welcome BYOND! (5.0 Beta Version 515.1609)
421 global variables
Loading config file config.txt...
Loading config file lobby.txt...
Loading config file topic.txt...
Loading config file linux_specific.txt...
Loading config file resources.txt...
Loading config file cdn_rsc_urls.txt...
Loading config file dbconfig.txt...
Duplicate setting for instance_name (cm13-live, config.txt) detected! Using latest.
Loading config file stats.txt...
Loading config file maps.txt...
Loading config file shipmaps.txt...
Loading config file topic_rate_limit_whitelist.txt...
TGS Info: Activating API for version 5.6.1
Running CMSS13 revision: 2023-07-18T19:06:46+00:00
origin/master: 0408eca6da8d1106df961ce63599ac9740e35da9
Test merge active of PR #3676 commit 22e1d929bf73b60ead2324db62d050a08ca3af9c
Test merge active of PR #3783 commit 0c6722c470b06f59b5578f1f9e0631ba5011a2f2
Test merge active of PR #3729 commit 16b30ac8f29137ea3d382217a453ed9a2cb7bf9c
Test merge active of PR #3850 commit 3190146bfeb712175f657494ec9af9196f467ab4
Test merge active of PR #3879 commit 442019a3d5b99b60e51327b6863ebdf61811217a
Test merge active of PR #3749 commit 19f32dfa4ec982afdc759efbb5e695dcde2a69b3
Test merge active of PR #3909 commit b1699379ffcac3400b9b8ec5e76af2c083a0845c
Test merge active of PR #3908 commit 270557fdcdd64110bd8035f8dd1c1cc08d21e84d
HEAD: f006b0af7e77d6369b52eab528b4e310c1683432
BUG: Crashing due to an illegal operation!
proc name: log admin (/proc/log_admin)
source file: code/__HELPERS/logging.dm,60
usr: (src)
src: null
call stack:
log admin("Loading jobban_rank")
jobban loadbanfile()
world: New()

Backtrace for BYOND 515.1609 on Linux:
Generated at Tue Jul 18 21:55:26 2023

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ba04]
libc.so.6 [0xf717d000, 0x0], 0x8b5b6
linux-gate.so.1 [0xf7f99000, 0xf7f99580], [0xf7f99000, 0xf7f99580]
libc.so.6 [0xf717d000, 0x0], 0x8b5b6
librust_g.so [0xf5bd9000, 0x0], 0x895f3
librust_g.so 0xb19f0, 0xb1a23
libbyond.so [0xf789d000, 0x0], 0x38e172
libbyond.so [0xf789d000, 0x0], 0x366aac
libbyond.so [0xf789d000, 0x0], 0x33648e
libbyond.so [0xf789d000, 0x0], 0x3598bc
libbyond.so [0xf789d000, 0x0], 0x33259f
libbyond.so [0xf789d000, 0x0], 0x3598bc
libbyond.so [0xf789d000, 0x0], 0x33259f
libbyond.so [0xf789d000, 0x0], 0x357e45
libbyond.so 0x47a940, 0x47aa39
libbyond.so 0x42f8f0, 0x42faf3
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804d15c]
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804b39a]
libc.so.6 0x1ad40, 0x1ae46 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804ad71]

Recent proc calls:
/datum/controller/configuration/proc/Get
/proc/time_stamp
/proc/log_admin
/proc/jobban_loadbanfile
/datum/admins/proc/associate
/proc/GenerateToken
/datum/admins/New
/datum/feed_channel/proc/(init)
/datum/admins/proc/(init)
/proc/trim_left
/proc/trim_right
/proc/trim
/proc/file2list
/proc/process_rank_file
/proc/trim_left
/proc/trim_right
/proc/trim
/proc/file2list
/proc/process_rank_file
/proc/trim_left
/proc/trim_right
/proc/trim
/proc/file2list
/proc/process_rank_file
/datum/admins/proc/associate
/proc/GenerateToken
/datum/admins/New
/datum/feed_channel/proc/(init)
/datum/admins/proc/(init)
/proc/trim_left
/proc/trim_right
/proc/trim
/proc/file2list
/proc/process_rank_file
/datum/admins/proc/associate
/proc/GenerateToken
/datum/admins/New
/datum/feed_channel/proc/(init)
/datum/admins/proc/(init)
/proc/trim_left
/proc/trim_right
/proc/trim
/proc/file2list
/proc/process_rank_file
/datum/admins/proc/associate
/proc/GenerateToken
/datum/admins/New
/datum/feed_channel/proc/(init)
/datum/admins/proc/(init)
/proc/trim_left
/proc/trim_right
/proc/trim
/proc/file2list
/proc/process_rank_file
/datum/admins/proc/associate
/proc/GenerateToken
/datum/admins/New
/datum/feed_channel/proc/(init)
/datum/admins/proc/(init)
/proc/trim_left
/proc/trim_right
/proc/trim
/proc/file2list
/proc/process_rank_file

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


We were able to swap back to the closed beta and operate normally again.

The line number faulting is
WRITE_LOG(GLOB.world_game_log, "ADMIN: [text]")

where WRITE_LOG is
#define WRITE_LOG(log, text) rustg_log_write(log, text, "true")

bringing us to
rustg_log_write(GLOB.world_game_log, "ADMIN: [text]", "true")

where rustg_log_write is
#define rustg_log_write(fname, text, format) RUSTG_CALL(RUST_G, "log_write")(fname, text, format)

and RUSTG_CALL is
#if DM_VERSION >= 515
#define RUSTG_CALL call_ext
#else
#define RUSTG_CALL call
#endif

So the result should be:
call_ext(RUST_G, "log_write")(GLOB.world_game_log, "ADMIN: [text]", "true")


IIRC this would be rust_g version 1.2.0. We have not tried again bumping to a newer version (2.1.0) yet.
Jul 19 2023, 12:11 am
Are you able to narrow this down at all, preferably with a test DLL project I can compile?

My old test DLL project (I forget who wrote the project for the DLL it uses) is not crashing with this when I pass strings to it, although it doesn't do anything with those strings. Now I did change up the way the memory for the strings is allocated, and that's really the only thing I can think of that could be causing issues. I can try switching back to the old way, but I can't confirm if that fixes the issue if I can't replicate it.
Jul 19 2023, 1:06 am (Edited on Jul 19 2023, 2:16 am)
Heres a tester that is able to reproduce the problem (see below though - I think I didn't actually):
https://1drv.ms/u/s!AjVBVtsdDUrrg8kja0anvvpGqg7Lmw?e=eQSeul

[drathek@drathek-ms7882 bin]$ ./DreamMaker ../../Tester/Tester
DM compiler version 515.1609
loading Tester.dme
saving Tester.dmb
Tester.dmb - 0 errors, 0 warnings (7/18/23 11:49 pm)
Total time: 0:00
[drathek@drathek-ms7882 bin]$ ./DreamDaemon ../../Tester/Tester -trusted
Tue Jul 18 23:49:49 2023
World opened on network port 36043.
Welcome BYOND! (5.0 Beta Version 515.1609)
runtime error: /home/drathek/Downloads/byond/bin/libbyond.so: undefined symbol: log_write
proc name: New (/world/New)
usr: null
src: world
call stack:
world: New()
The BYOND hub reports that port 36043 is not reachable.
^CShutting down...


(I did leave an accidental duplicate define for RUSTG_CALL in world.dm, but even if you remove the extra one the problem is still replicated)

I do not reproduce the problem on windows with this tester; also I do not reproduce the problem using a newer version of rust_g. The version provided in this tester should be 1.2.0 of rust_g.

Apologies if this is actually just a weird rust_g issue with the version we happened to be using at the time, but MSO seemed fairly certain this was a byond bug.
Jul 19 2023, 1:30 am (Edited on Jul 19 2023, 1:42 am)
This also may be related, but for above with my current linux installation (Manjaro on 515.102-1), if I LDD that .so file it has two missing links:
[drathek@drathek-ms7882 bin]$ ldd ../../Tester/librust_g.so
ldd: warning: you do not have execution permission for `../../Tester/librust_g.so'
linux-gate.so.1 (0xf7f54000)
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
libz.so.1 => /usr/lib32/libz.so.1 (0xf77ea000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf77c5000)
libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf77c0000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf76ef000)
libdl.so.2 => /usr/lib32/libdl.so.2 (0xf76ea000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf74bf000)
/usr/lib/ld-linux.so.2 (0xf7f56000)

Whereas the latest version of the rust_g library which works w/ the tester has the links found:
[drathek@drathek-ms7882 bin]$ ldd ../../librust_g.so
ldd: warning: you do not have execution permission for `../../librust_g.so'
linux-gate.so.1 (0xf7ece000)
libssl.so.3 => /usr/lib32/libssl.so.3 (0xf77f4000)
libcrypto.so.3 => /usr/lib32/libcrypto.so.3 (0xf73b6000)
libz.so.1 => /usr/lib32/libz.so.1 (0xf739d000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7378000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf72a7000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf707c000)
/usr/lib/ld-linux.so.2 (0xf7ed0000)


However, it doesn't make sense why going from closed beta 1609 to non-closed beta 1609 with I assume the same rust_g binary broke for us, and then returning back to closed beta worked again.

So actually I may also be failing to replicate the issue in this little tester that uses rust_g, and if so I'm not really sure what else might be related.
Jul 19 2023, 1:22 pm
Lummox JR resolved issue with message:
call_ext() with older-style string-only calls was passing null pointers to the external library in some cases instead of blank strings, which caused problems for libraries that expected non-blank strings.