Segmentation Fault #6

ryandotnet · 2018-04-24T08:47:21Z

I'm getting the following error printed out when trying to Test/Connect.
"Segmentation Fault"

Added TCP_NODELAY to server.c and make > make install with no errors. Tried WITHOUT TCP_NODELAY, still given "Segmentation Fault" upon Auth.

Adding Auth with "-u test -P test" causes Auth to fail first time then cause "Segmentation Fault" on the second try. Having no Auth set instantly closes the server with "Segmentation Fault" again.

Upon adding every command line possible "server_setup: Success" but not running.

Any ideas as to why this is happening?

rofl0r · 2018-04-26T18:46:35Z

maybe yet another issue due to stack size. what system is this ? please give detailed info like Ubuntu 14.14 x86_64

ryandotnet · 2018-04-26T18:58:13Z

I had thought it would be something like that. I've tested it on the following:
Debian 8.0 x86_64 3.16.0-4
Ubuntu 16.04 x86_64 4.15.0-15

I did the following:
git clone https://github.com/rofl0r/microsocks
make
make install

rofl0r · 2018-04-26T19:10:43Z

try this, change line 416 from

size_t stacksz = MAX(8192, PTHREAD_STACK_MIN); /* 4KB for us, 4KB for libc */

to

size_t stacksz = 512 * 1024;

then run make and make install again

ryandotnet · 2018-04-26T19:44:41Z

That fixed the issue! It builds and runs without issues now!! Thank you (:

rofl0r · 2018-04-27T22:41:11Z

great! would you be so kind as to try out some other sizes to find the "sweet spot" ?
maybe try with 256, 128, and maybe 64 KB.

ryandotnet · 2018-04-28T11:24:45Z

Yea sure! You just want me to change the "512" in "512 * 1024" right? And keep going until segmentation fault happens again?

rofl0r · 2018-04-29T00:38:41Z

yes, exactly. thanks!

ryandotnet · 2018-04-29T17:21:35Z

Just finished testing and found some new issues..

I tried between 8 and 512 (8, 16, 32, 64, 128, 256, 512) and they all worked. However, I've encountered a few new issue.

User/Pass Auth always fails the first time, no matter what stack size I use. The second time always succeeds though.
After it succeeds on the second attempt, it will never succeed again / keeps failing with incorrect user/pass until microsocks is restarted. If I launch with "-1" parameter, it will allow you to connect after successfully authing (on the second attempt) IF you have no auth set.
If no Auth is set, everything works smoothly (:

Is this intended? If it is, is there a way I can get it to accept auth every time (and fix the possible first-attempt auth fail)? Thanks!

rofl0r · 2018-04-29T23:13:38Z

I tried between 8 and 512 (8, 16, 32, 64, 128, 256, 512) and they all worked.

that doesn't make sense. it probably means you tested the wrong binary (i.e. you were continuing to use the old one that worked, since changing the value from 8 to 512 fixed your issue originally.

User/Pass Auth always fails the first time, no matter what stack size I use. The second time always succeeds though.

what program are you doing the testing with ?

in my test:
terminal 1:

$ ./sockssrv.out -u user -P pass
client[5] 127.0.0.1: connected to xx.xx.xx.xx:80
client[4] 127.0.0.1: connected to xx.xx.xx.xx:80
client[5] 127.0.0.1: connected to xx.xx.xx.xx:80

terminal 2:

~ $ curl --socks5 user:pass@localhost:1080 google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
~ $ curl --socks5 user:pass@localhost:1080 google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
~ $ curl --socks5 user:pass@localhost:1080 google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
~ $ curl --socks5 user:passX@localhost:1080 google.com
curl: (7) User was rejected by the SOCKS5 server (5 2).

ryandotnet · 2018-04-30T05:47:24Z

I'm actually using a Windows Proxy Checker found here: https://www.proxifier.com/download/

I'm definitely removing/deleting the old binary and rebuilding it with a new make & make install. Perhaps I should just with curl on another linux box. I'll report back as soon as I can!

ryandotnet · 2018-04-30T13:08:10Z

Alright after extensive testing: It seems the problem was with the proxy checker. Although this other I'm one using gives me: "Socks5 PROTOCOL ERROR", but we can just ignore that as it's exclusive to ProxyCap.

As for the stack size: 8 -> 512 works perfectly fine with:
size_t stacksz = 8 * 1024;

However, when I change it back to:
size_t stacksz = MAX(8192, PTHREAD_STACK_MIN);

I get segmentation fault.

rofl0r · 2018-05-01T04:14:11Z

huh. could you try putting this line after the MAX stuff ?

dprintf(2, "%zu\n", stacksz);

and tell me what it says ?

ryandotnet · 2018-05-02T19:27:21Z

Sure!

With: size_t stacksz = MAX(8192, PTHREAD_STACK_MIN);
It prints: 16384

With: size_t stacksz = 8 * 1024;
It Prints: 8192

If I do: size_t stacksz = 16 * 1024;
It Prints: 16384 and gives Segmentation Fault

I think it's pretty safe to say that having a stackz size of 16384 is causing it to crash O:

rofl0r · 2018-05-03T17:44:31Z

With: size_t stacksz = MAX(8192, PTHREAD_STACK_MIN);
It prints: 16384

interesting. so now it works with the default ?

ryandotnet · 2018-05-03T17:54:46Z

No no. It fails with the default. As long as the stackz size prints/is : 16384, it will give "Segmentation Fault".

So with: size_t stacksz = MAX(8192, PTHREAD_STACK_MIN);
It will Print: 16384 and give Segmentation Fault

With: size_t stacksz = 16 * 1024;
It will print: 16384 and give Segmentation Fault as well.

So anything that sets STACKZ to 16384 will give Segmentation fault (Including the default config/line).
And of course, just setting stacksz size to 8192 fixes it and all is well (:

rofl0r · 2018-05-05T07:06:50Z

...
that doesn't make sense. if it crashes, then it is due to too little stack.
so if it crashes with 16K, it should crash with 8K too...

ryandotnet · 2018-05-05T07:15:17Z

Hmm.. I'm not sure as to why it crashes either :/ But it only seems to crash at 16384. It doesn't crash at 8192 or 4096. I haven't tried lower though.

according to reports from a user of Debian 9 x86 (32-bit), getaddrinfo() would crash at times with the default stacksize. addresses #6

ryandotnet closed this as completed Jul 2, 2018

rofl0r added a commit that referenced this issue Jul 9, 2018

increase stacksize for GLIBC

12dcb0e

according to reports from a user of Debian 9 x86 (32-bit), getaddrinfo() would crash at times with the default stacksize. addresses #6

rofl0r mentioned this issue Aug 22, 2018

Cross-compilation on arm and mips devices #7

Open

rofl0r mentioned this issue Mar 29, 2020

Always crash on FreeBSD 9 #21

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Segmentation Fault #6

Segmentation Fault #6

ryandotnet commented Apr 24, 2018

rofl0r commented Apr 26, 2018

ryandotnet commented Apr 26, 2018 •

edited

Loading

rofl0r commented Apr 26, 2018

ryandotnet commented Apr 26, 2018

rofl0r commented Apr 27, 2018

ryandotnet commented Apr 28, 2018

rofl0r commented Apr 29, 2018

ryandotnet commented Apr 29, 2018 •

edited

Loading

rofl0r commented Apr 29, 2018

ryandotnet commented Apr 30, 2018

ryandotnet commented Apr 30, 2018 •

edited

Loading

rofl0r commented May 1, 2018

ryandotnet commented May 2, 2018 •

edited

Loading

rofl0r commented May 3, 2018

ryandotnet commented May 3, 2018 •

edited

Loading

rofl0r commented May 5, 2018

ryandotnet commented May 5, 2018

Segmentation Fault #6

Segmentation Fault #6

Comments

ryandotnet commented Apr 24, 2018

rofl0r commented Apr 26, 2018

ryandotnet commented Apr 26, 2018 • edited Loading

rofl0r commented Apr 26, 2018

ryandotnet commented Apr 26, 2018

rofl0r commented Apr 27, 2018

ryandotnet commented Apr 28, 2018

rofl0r commented Apr 29, 2018

ryandotnet commented Apr 29, 2018 • edited Loading

rofl0r commented Apr 29, 2018

ryandotnet commented Apr 30, 2018

ryandotnet commented Apr 30, 2018 • edited Loading

rofl0r commented May 1, 2018

ryandotnet commented May 2, 2018 • edited Loading

rofl0r commented May 3, 2018

ryandotnet commented May 3, 2018 • edited Loading

rofl0r commented May 5, 2018

ryandotnet commented May 5, 2018

ryandotnet commented Apr 26, 2018 •

edited

Loading

ryandotnet commented Apr 29, 2018 •

edited

Loading

ryandotnet commented Apr 30, 2018 •

edited

Loading

ryandotnet commented May 2, 2018 •

edited

Loading

ryandotnet commented May 3, 2018 •

edited

Loading