ID:930315
 
Keywords: browse_rsc, crash
BYOND Version:496
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Palemoon 12.2.1
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Using browse_rsc to output an /icon datum will often crash Dream Seeker.

[Edit: I should also add that this project is compiled in Windows 7, but runs on Ubuntu.]

I have this bit from the windows crash dialog, I'm unsure if it helps at all:
Problem signature:
Problem Event Name: APPCRASH
Application Name: dreamseeker.exe
Application Version: 4.0.496.1143
Application Timestamp: 4ffb463d
Fault Module Name: byondcore.dll
Fault Module Version: 4.0.496.1143
Fault Module Timestamp: 4ffb4605
Exception Code: c0000005
Exception Offset: 00056519
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


Numbered Steps to Reproduce Problem:
1) create arbitrary /icon datum using the icon() proc
2) attempt to browse_rsc this datum as any filename
3) about 60% of the time your client crashes

Code Snippet (if applicable) to Reproduce Problem:
Just one of several browse_rsc calls that crashes DS:
proc
preload_rank_images(mob/pc/character/member)
if(isicon(src.rank_images))
for(var/r in icon_states(src.rank_images,1)) member << browse_rsc(icon(src.rank_images,r),"[md5("[src.name][r]")].png")


Expected Results:
browse_rsc sticks the icon in my BYOND cache, allowing me to use it in subsequent browse() calls.

Actual Results:
Dream Seeker crashes, and does that faded-out looking thing Windoze 7 does with an overlayed dialog box stating the program crashed.

Does the problem occur:
Every time? Or how often? Quite often, but not every time. I'd guesstimate about 60% of the time.
In other games? Don't know.
In other user accounts? Yes.
On other computers? Yes, several others are becoming crashed by the same code.

When does the problem NOT occur?
Earlier iterations of the above code snippet that did not cause a problem would browse_rsc a single-quoted cache file instead of an arbitrary runtime icon resource. I think using cache resources directly does not cause this problem.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
493 was the first version I started noticing this happening, but I know there was a significant gap in my updating prior and I no longer recall the last version this wasn't happening.

Workarounds:
Don't browse_rsc an /icon, it seems.
The trace shows me where this is crashing but it's not especially clear why. The code appears to be trying to free an icon that no longer exists. It would help to have an example project where this happens frequently.
I'm currently in a situation where I can't even login to my game due to the above code exploding my client immediately. I can get you whatever you need in minutes if you have a special debug Seeker or something.

Alternatively, I can just give you my key and you can see it happen firsthand.
While it's probably unlikely to make a difference, one thing I suggest trying is calling fcopy_rsc() on the icon() call first. Just wrap your icon() call in that; I'm curious if it will make a difference. Also judging by your code it seems you're using TILED_ICON_MAP; can you confirm that?

It can't hurt to send me the source but I'm not sure when I'll have a chance to get to it. Hopefully soon.

Bah, the owner of the problematic set of rank images changed the file and I'm not being crashed any more. It happens with enough frequency, I'm sure it'll appear again soon.

I'll try out fcopy_rsc, and I'm using TOPDOWN_MAP.
If you're using TOPDOWN_MAP then the extra argument in icon_states() is moot, but it doesn't hurt anything being there.

If you can find the file responsible, that's probably going to be a smoking gun. My guess is there's something fundamentally wrong with it. I'm not sure how your game is setup so that users can change the files like this, but if you have a way of knowing what file caused it, that would be helpful.
I haven't been able to nail it down to a single file before, but the owner of it no longer has the "broken" version, given it's the same one he loaded before and after the crashing with altered icon state contents. At any rate, shouldn't a broken file be trapped somewhere along the line before causing a full client crash on a browse_rsc call?

The file seems to upload fine and work without issue in an output control (using img src=\ref[icon]) but dumping the icon states into the cache for use in browser windows blows up the client.