New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Freeze while resizing the variable array multiple times #920

Closed
carstene1ns opened this Issue Jul 3, 2016 · 4 comments

Comments

Projects
None yet
4 participants
@carstene1ns
Member

carstene1ns commented Jul 3, 2016

Name of the game: thouhou alive 1.07 (東方ALIVE)

Player platform: Android (likely all)

Describe the issue in detail and how to reproduce it:

The variable array is endlessly increased by some event, making the game unresponsive.
Issue submitted by mail:

A movie stops at a prolog by the illusion volume. Is this the bug?

Log excerpt:

[2016-07-03 18:17:28] Debug: Loading Map Map0557.lmu
[2016-07-03 18:17:28] Debug: Tree: VS魔理沙 < マヨヒガ城 < 幻想編Chapter1
[2016-07-03 18:17:57] Debug: Resizing variable array to 1101 elements.
[...]
[2016-07-03 18:23:46] Debug: Resizing variable array to 71587 elements.

@fdelapena fdelapena added this to the 0.4.2 milestone Jul 3, 2016

@fdelapena

This comment has been minimized.

Show comment
Hide comment
@fdelapena

fdelapena Jul 13, 2016

Contributor

It happens with both original or translated version.

Game download (Japanese, unpack with unar).
Game download (English translation by vgperson).

How to reproduce:

easyrpg-player --start-map-id 557

It starts after a couple of seconds, goes black screen, event with ID 0 exceeds execution limit a few times while increasing some array size elements.

It happens after displaying the "beaten" message, maybe it should display some defeat / game over sequence, as it goes later to the title screen after the huge array resize.

After 71587 elements resizing it goes to the title screen.
With the vgperson's translated version it ends after 76587 elements.

I guess this map should be set as the srtarting position and test with RPG_RT first.

Contributor

fdelapena commented Jul 13, 2016

It happens with both original or translated version.

Game download (Japanese, unpack with unar).
Game download (English translation by vgperson).

How to reproduce:

easyrpg-player --start-map-id 557

It starts after a couple of seconds, goes black screen, event with ID 0 exceeds execution limit a few times while increasing some array size elements.

It happens after displaying the "beaten" message, maybe it should display some defeat / game over sequence, as it goes later to the title screen after the huge array resize.

After 71587 elements resizing it goes to the title screen.
With the vgperson's translated version it ends after 76587 elements.

I guess this map should be set as the srtarting position and test with RPG_RT first.

@fdelapena fdelapena added Performance and removed Hang labels Jul 21, 2016

@fdelapena fdelapena modified the milestones: 0.6.0, 0.5.0 Jul 21, 2016

@carstene1ns carstene1ns changed the title from Freeze while resizing the variable array (endless recursion?) to Freeze while resizing the variable array multiple times Jul 31, 2016

@Ghabry Ghabry modified the milestones: 0.5.1, 0.6.0 Jan 26, 2017

@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Jan 26, 2017

Member

Have a patch which makes the resizing more efficient (always reserve id + 1000) and the output less verbose (only 10 per run).

Member

Ghabry commented Jan 26, 2017

Have a patch which makes the resizing more efficient (always reserve id + 1000) and the output less verbose (only 10 per run).

Ghabry added a commit to libretro/easyrpg-libretro that referenced this issue May 22, 2018

Ghabry pushed a commit to libretro/easyrpg-libretro that referenced this issue May 22, 2018

@Zegeri

This comment has been minimized.

Show comment
Hide comment
@Zegeri

Zegeri Aug 8, 2018

Member

Have a patch which makes the resizing more efficient (always reserve id + 1000)

I'm not sure why would that be more efficient. This reallocates the vector every time, not when the capacity has been reached. This means that the whole vector could be reallocated 76587 times.

Member

Zegeri commented Aug 8, 2018

Have a patch which makes the resizing more efficient (always reserve id + 1000)

I'm not sure why would that be more efficient. This reallocates the vector every time, not when the capacity has been reached. This means that the whole vector could be reallocated 76587 times.

@Ghabry

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry Aug 8, 2018

Member

You are right, without checking capacity() the patch makes no sense at all.

Member

Ghabry commented Aug 8, 2018

You are right, without checking capacity() the patch makes no sense at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment