n2n-route tool generates infinite processes of n2n-route.exe and cmd.exe

[wolf109909]

I have compiled n2n with msys2 ucrt environment. build config: ./configure --with-zstd --with-openssl --enable-pthread --enable-miniupnp --enable-natpmp CFLAGS="-O3" adding march=native will cause random_numbers.c failing to compile. starting up n2n-route.exe is destructive to windows as it will create infinite processes of itself on every single instance. only killable if you run the tool in a cmd and when you close the cmd window it seem to kill every single instance of n2n-route.exe automatically.

[wolf109909]

I am a fucking idiot

[wolf109909]

OK, so here's what happened: I have created a bat file route.bat , which perfectly conflicted with line 486 in n2n-route.c where the route command for windows is created, thus I created a fork bomb myself by accident.

[Logan007]

Hi there,

So, I get that the issue with the processes is solved, right? What is the exact parameter to the tool that made it go nuts? Line 486 is about adding or deleting a route.

With a view to random_numbers.c, I think it might be defining a variable in/outside a hardware-specific block. Can you confirm this from the compiler's error message? What exact CPU do you use?

[wolf109909]

Yes, the issue I had initially was solved by simply renaming the bat file. I named my bat file route.bat which somehow made the command route being overridden. and when the n2n-route trying to add or remove a route, it just starts up another n2n-route.exe. as for the random_numbers.c, here are the compiler output:

src/random_numbers.c:129:9: error: 'i' undeclared (first use in this function); did you mean 'ip'?
  129 |     for(i = 0; i < RND_RETRIES; i++) {
      |         ^
      |         ip

this error doesn't make much sense to me at first glance so I just decide to remove march=native. my cpu is Ryzen 5800H.

[Logan007]

this error doesn't make much sense to me at first glance so I just decide to remove march=native. my cpu is Ryzen 5800H.

I think this can be fixed soon, maybe by giving each (un-/deffed) block a separate counter variable.

[wolf109909]

this error doesn't make much sense to me at first glance so I just decide to remove march=native. my cpu is Ryzen 5800H.

I think this can be fixed soon, maybe by giving each (un-/deffed) block a separate counter variable.

Maybe even just by add a int before i so it gets declared inline

[Logan007]

Maybe even just by add a int before i so it gets declared inline

I remember we had it exactly like this once, but it gave compile errors/warnings on some other systems adhering to some specific C standard, so we refrained from it again... ;)

[wolf109909]

Maybe even just by add a int before i so it gets declared inline

I remember we had it exactly like this once, but it gave compile errors/warnings on some other systems adhering to some specific C standard, so we refrained from it again... ;)

ahhh. I understand now. multiplatform support for a C program is pretty headache xDD