2018-06-22 16:08 EDT


View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0002957FSSCPmultiplayerpublic2013-11-20 01:43
Reporterchief1983 
Assigned Tochief1983 
PrioritynormalSeveritycrashReproducibilityhave not tried
StatusresolvedResolutionfixed 
Platformx86-64OSFreeBSDOS Version9.2
Product Version3.7.1 
Target Version3.7.2Fixed in Version 
Summary0002957: *nix Standalone crash on assertion failure
DescriptionBeam couldn't find a good object model/type!! (0)
Beam couldn't find a good object model/type!! (0)
vm_forward_interpolate: Bad rotation
vm_forward_interpolate: Bad rotation
ASSERTION: "RAND_MAX == 0x7fffffff" at systemvars.cpp:123
Steps To ReproduceHad two Windows 7 clients connected to the WebUI standalone on my FreeBSD machine, running r10121, playing Aeolus Duel, when a couple minutes in, the standalone server crashed out with the assertion above.
Additional InformationI'm guessing RAND_MAX isn't 0x7fffffff or 0x7fff on this particular platform. The rand32 function probably needs to be expanded to be more flexible, like maybe supporting any number of bits between 16 and 32, or possibly a RAND_MAX higher than 32 bits. Not sure what the case was here when it crashed, other than it broke.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0015425

chief1983 (administrator)

From the /usr/include/stdlib.h on FreeBSD 9.2:
#define RAND_MAX 0x7ffffffd

rand32() assumes it is either 0x7fff (MSVC, etc) and goes one way, or Asserts that it is 0x7fffffff, which it is not quite on FreeBSD, leading to a debug build crash when rand32 is called. Surprised it took me a few minutes of playing to crash, must not be called except in certain situations.

So it looks like rand32 could use a slight overhaul, maybe to at least make sure that if RAND_MAX is not 0x7fffffff, that we try to make a 32bit random number out of however many bits we do have.

~0015426

chief1983 (administrator)

Last edited: 2013-11-19 15:38

View 2 revisions

More info on the FreeBSD RAND_MAX change found via http://freebsd.1045724.n5.nabble.com/RAND-MAX-issue-td5839987.html

Maybe consider upgrading to the Mersenne Twister http://www.bedaux.net/mtrand/

~0015428

chief1983 (administrator)

This issue was created by 0001823. Assert(RAND_MAX >= 0x7ffffffd); would probably handle this, and let us catch any with a RAND_MAX between MSVC and FreeBSD in the future.

~0015432

chief1983 (administrator)

Fix committed to trunk@10129.
+Notes

+Related Changesets

-Issue History
Date Modified Username Field Change
2013-11-19 01:23 chief1983 New Issue
2013-11-19 14:59 chief1983 Note Added: 0015425
2013-11-19 15:35 chief1983 Note Added: 0015426
2013-11-19 15:38 chief1983 Note Edited: 0015426 View Revisions
2013-11-19 17:52 chief1983 Assigned To => karajorma
2013-11-19 17:52 chief1983 Status new => assigned
2013-11-19 18:05 chief1983 Note Added: 0015428
2013-11-19 18:28 chief1983 Assigned To karajorma => chief1983
2013-11-20 01:43 chief1983 Changeset attached => fs2open trunk r10129
2013-11-20 01:43 chief1983 Note Added: 0015432
2013-11-20 01:43 chief1983 Status assigned => resolved
2013-11-20 01:43 chief1983 Resolution open => fixed
+Issue History