"Segmentation fault" error when shiny is found

[ProH4Ck]

When bot found a shiny crashes with a segmentation fault error.
The state is saved (if I restart emulator state is reloaded with shiny encounter) but the bot crash

I use Linux Debian

[hanzi]

Are you using any of the Discord or OBS integrations?

[ProH4Ck]

No. I just use http server with a software I wrote connected to api.
I'm running 3 instances of the emulator side-by-side.. this could be a problem?
All http server are running on different ports and everything works until a shiny is found.

[hanzi]

Yes, that might be what's causing it.

It shouldn't be, but the HTTP server runs in a separate thread and so it's possible that if you're calling the wrong endpoint at the wrong time (while something is writing to the database or whatever) we get some race condition. I've seen it happen before.

What does your API client do when you encounter a shiny? Could you just post a list of calls it would make to the API? Then I'll try to reproduce the issue.

[ProH4Ck]

AI powered description of my shiny encounter workflow.
The agent is my software monitoring pokebot instances.
I can insert a delay between SSE shiny event and first call to check catch status...

Overview

The agent does not send any command, POST, PUT, or emulator-control request to PokéBot when a shiny is found. All PokéBot-facing requests in this workflow are GETs.

1. The agent already has this long-lived SSE connection open:

   GET {BotBaseUrl}/stream_events?topic=WildEncounter&topic=BotMode&topic=Message
   

   A shiny workflow starts only when a WildEncounter event contains:

   {
     "encounter_id": 123,
     "pokemon": {
       "is_shiny": true,
       "species": { "index": 1 }
     }
   }

2. The agent starts an asynchronous capture-confirmation workflow. It does not block the SSE stream or the regular snapshot loop.

Normal Wild Encounter Path

The agent polls the encounter outcome:

GET {BotBaseUrl}/encounter_log

• The first request is immediate.
• It repeats roughly once per second while the matching encounter_id is missing, has no outcome, or has outcome == "InProgress".
• This poll has no overall timeout. It continues until the agent stops or PokéBot returns a terminal outcome.
• If the outcome is anything other than exactly Caught, the workflow stops here. No shiny-log read and no final ShinyEncounter event are produced.

If the outcome is Caught, the agent waits for PokéBot’s party/storage cache to expose the caught Pokémon:

GET {BotBaseUrl}/party
GET {BotBaseUrl}/pokemon_storage

Those two requests are issued concurrently, immediately on the first attempt, then approximately once per second until the detected species count increases by one. This retry loop has a 30-second deadline, so it can issue up to roughly 31 request pairs (about 62 GETs) in the worst case.

Once the new shiny is visible in party or storage, the agent makes one final read:

GET {BotBaseUrl}/shiny_log

Independent Traffic That Can Overlap This Workflow

The agent also runs snapshots every configured interval (30 seconds in the checked-in configuration; never less than 10 seconds). These calls are not triggered by the shiny itself, but can run concurrently with the confirmation workflow:

GET /stats
GET /emulator
GET /party
GET /pokemon_storage
GET /encounter_rate
GET /map_encounters
GET /event_flags
GET /items
GET /map              // normal non-fishing/non-starter mode
GET /player           // fishing mode instead of /map