[Scummvm-tracker] [ScummVM] #9705: FULLPIPE: Crash on start

[Colin Snover]

#9705: FULLPIPE: Crash on start
----------------------+------------------------------
  Reporter:  raziel-  |      Owner:  (none)
      Type:  defect   |     Status:  new
  Priority:  blocker  |  Component:  Engine: Fullpipe
Resolution:           |   Keywords:  has-backtrace
      Game:           |
----------------------+------------------------------

Comment (by csnover):

 Unfortunately it is still just consistently newlib crashing when
 allocating more memory.

 This engine peaks at 180MiB on startup on my machine, which is quite a lot
 compared to Starship Titanic or SCI32 which both use less than 40MiB. I am
 not sure if there are any other engines in ScummVM that use so much
 memory.

 If you are getting super unlucky, newlib might be doing a poor job of
 managing the many small allocations and running out of pages or something
 even if there is enough physical RAM to handle the load. I’m not blown
 away by the difference in number of allocations, it makes about 2.5x the
 number of allocations made by SCI32, though these are more frequently very
 small (16 byte) allocations. At face value, this doesn’t seem like
 something that should be breaking. You might try creating a small test app
 that makes a lot of small heap allocations and see what happens.

 For reference here are some rough numbers on the top 10 allocations by
 total number of allocations at startup of the full version of Full Pipe on
 my system, which you might be able to use to create some synthetic test
 app to crash the allocator:

 {{{
 Category        Persistent Bytes        # Persistent    # Transient
 Total Bytes     # Total # Transient/Total
 Malloc 16 Bytes 49.31 KiB       3156    22787   405.36 KiB      25943
 Ratio: %0.01, %0.08
 Malloc 32 Bytes 403.00 KiB      12896   9658    704.81 KiB      22554
 Ratio: %0.05, %0.03
 Malloc 4.00 KiB 300.00 KiB      75      9776    38.48 MiB       9851
 Ratio: %0.00, %0.03
 StdioStream     32 Bytes        1       9690    302.84 KiB      9691
 Ratio: %0.00, %0.03
 Common::MemoryReadStream        528 Bytes       11      9671    453.84 KiB
 9682    Ratio: %0.00, %0.03
 Fullpipe::MemoryObject2 992.14 KiB      9071    0       992.14 KiB
 9071    Ratio: %0.03, %0.00
 Malloc 1.00 KiB 8.57 MiB        8774    29      8.60 MiB        8803
 Ratio: %0.03, %0.00
 Fullpipe::DynamicPhase  1.84 MiB        8579    0       1.84 MiB
 8579    Ratio: %0.03, %0.00
 Fullpipe::GameVar       572.25 KiB      5232    0       572.25 KiB
 5232    Ratio: %0.02, %0.00
 Malloc 128 Bytes        152.00 KiB      1216    2685    487.62 KiB
 3901    Ratio: %0.00, %0.01
 }}}

 There’s a fairly long tail of other allocations (total numbers are 69580
 persistent, 84454 transient) but this seems like a place to start.

 Hopefully we will be able to collect a bit more data during release
 testing to see if there are any other systems which have this problem,
 though I am not really sure outside of the big-five how many other
 platforms are even going to be powerful enough to run this game
 regardless.

--
Ticket URL: <https://bugs.scummvm.org/ticket/9705#comment:12>
ScummVM <https://bugs.scummvm.org>
ScummVM