Le 18/03/2020 à 04:21, Kevin Zhu a écrit :
Hi Christopher
Can you please test the config files I attached in this mail, HAProxy version 
And you can add some debug code like SPOE_PRINTF in function spoe_init_per_thread to print engin_ids of every agent in every proxy.
Then you can see the engine_id is duplicated.

The patch I attached in prev mail is worked, but I agree better to have a lock.

Hi Kevin,

Ok I understand now how you hit the bug. You use the same engine in 2 different frontends. Of course, it is totally valid. And there is indeed a bug here. And in fact, it reveals a design problem.

First, I confirm on 2.x versions, it should already be fixed by side effect. As I said, a new thread-safe and process-safe PRNG was implemented. Now, a specific state is chosen for each process child after the fork. The fix will be part of the next releases.

For the 1.9, It is annoying because each spoe engine will reset the random state with the same seed. With 2 spoe engines, it may be reset by the second one on the first thread while it is used to generate IDs of the first one on other threads. The problem exists for completely different engines. If you use more than one engine, you may hit the bug. So, the spoe_init_per_thread() callback function is definitely the wrong place to reset the random state. It must be done just after the fork, in the child process.

About your patch, on the 1.9 (or the version 2.1.3) with several threads, you may have the same engine ID for different threads, with just one engine. To convince you, replace nbproc by nbthread in your configuration and add a delay between the HA_ATOMIC_LOAD and the HA_ATOMIC_STORE. This will increase the probability to have duplicated engine IDs.

I'll try to push a fix for the 1.9. But I'm busy on another task for now. For 2.x versions, you may use the last snapshots to have the fix.

Christopher Faulet

Reply via email to