| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0002848 | Spring engine | General | public | 2011-12-18 17:21 | 2014-02-03 12:56 | ||||
| Reporter | Beherith | ||||||||
| Assigned To | jK | ||||||||
| Priority | normal | Severity | crash | Reproducibility | always | ||||
| Status | closed | Resolution | suspended | ||||||
| Product Version | 84.0 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0002848: Large maps (32x32) with many tiles crash with std::bad alloc() | ||||||||
| Description | I'm testing a 32x32 map, that uses 0 tiling compression (kill me), and it crashes spring when I load it up, after the following place (this is not the last in the stack trace, after this it crashes in vector.resize() ): spring.exe!IArchive::GetFile(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & name="maps/massive.smt", std::vector<unsigned char,std::allocator<unsigned char> > & buffer=[0]()) Line 60 + 0xf bytes C++ No stack trace is written to infolog, this is the stack from MSVC. The .smt is 178 megabytes large, here is an upload of the map if needed for testing. (100 megs, im sorry :( ) http://beherith.eat-peet.net/stuff/massive.sd7 Thank you very much! | ||||||||
| Additional Information | Win7 x64, 8gb ram (plenty free) | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
||||||
|
||||||
 Relationships |
| Notes |
|
|
Kloot (developer) 2011-12-18 18:04 Last edited: 2011-12-18 18:04 |
You need a 64-bit build of Spring to (safely) load such maps. |
|
hoijui (reporter) 2011-12-19 13:01 |
could/should we add some checks in places where we allocate large amounts of memory, to see if the target platform would even be capable of doing it? or .. i gess even better, catch failed-alloc-exceptions? |
|
Kloot (developer) 2011-12-19 21:50 Last edited: 2011-12-19 21:54 |
We could, but what would be the point? pros: * instead of crashing with an uncaught exception, Spring terminates "cleanly" via log() + exit() (and perhaps a pretty popup) cons: * code gets littered with try { ... } catch { ... } constructs * from a user perspective nothing changes (Spring still occasionally goes *poof* in the middle of loading) * checks if an allocation could succeed are unreliable without a custom memory pool/manager, so add no protection |
|
jK (developer) 2011-12-19 23:21 |
We already catch it. It's Beherith that had a MSVC debug build which intentionally don't catch them ... |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-12-18 17:21 | Beherith | New Issue | |
| 2011-12-18 18:04 | Kloot | Note Added: 0007955 | |
| 2011-12-18 18:04 | Kloot | Note Edited: 0007955 | |
| 2011-12-19 13:01 | hoijui | Note Added: 0007970 | |
| 2011-12-19 21:50 | Kloot | Note Added: 0007973 | |
| 2011-12-19 21:54 | Kloot | Note Edited: 0007973 | |
| 2011-12-19 23:21 | jK | Note Added: 0007974 | |
| 2012-01-31 16:08 | Kloot | Relationship added | has duplicate 0002869 |
| 2014-02-03 12:56 | jK | Status | new => closed |
| 2014-02-03 12:56 | jK | Assigned To | => jK |
| 2014-02-03 12:56 | jK | Resolution | open => suspended |
| Issue History |