Program segfaults when checking value of errno

[Frederick Virchanza Gotham]

I've run a desktop PC program (x86_64 MS-Windows) through the 'gdb' debugger and I can clearly see that it segfaults when it reads the value of 'errno'.

To try understand what's going on, I wrote a minimal program:

#include <errno.h>

int main(void)
{
return errno;
}

and then I compiled it with "-E -P" to get the preprocessor output:

extern int *__errno_location (void) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__));

int main(void)
{
return (*__errno_location ());
}

So, 'errno' is the dereferencing of the return_value from the invocation of a function.

So to get a segfault here, either '_errno_location' is a nullptr or invalid pointer, or the return value from its invocation is a nullptr or invalid pointer.

Anyone ever seen 'errno' cause a segfault?

[Kenny McCormack]

In article <aea44a82-92d5-4b04...@googlegroups.com>,

Frederick Virchanza Gotham <cauldwel...@gmail.com> wrote:
>
>I've run a desktop PC program (x86_64 MS-Windows) through the 'gdb'

>Idebugger and can clearly see that it segfaults when it reads the value

>of 'errno'.
>
>To try understand what's going on, I wrote a minimal program:
>
>#include <errno.h>
>
>int main(void)
>{
> return errno;
>}
>
>and then I compiled it with "-E -P" to get the preprocessor output:

It works OK for me. I note that you posted in C++, but this looks like a
pure C issue. Just to be clear, are you implying that it is a C++only
problem?

Anyway, here is my test program (running on Linux, with tcc):

#!/usr/bin/tcc -run

#include <errno.h>
#include <fcntl.h>

int main(void)
{
/* With this line, returns 2, without it, returns 0 */
int fd = open("/tmp/golisdf",0);
return errno;
}

Note: I'm not saying this is conclusive; just that I could not replicate
your issue. Generally, it should work, but it may be a Windows thing, it
could be a C++ thing, it might be a (whatever compiler you used) issue. It
could be lots of things.

Also, we are all aware that errno got changed recently for compatibility
reasons with threads. I don't know if tcc has that change or not.

--
I voted for Trump because I thought he'd make pussy grabbing legal.
I honestly don't see any other way America could be made great again.

[Frederick Virchanza Gotham]

On Saturday, February 11, 2023 at 12:29:39 AM UTC, Kenny McCormack wrote:
>
> Note: I'm not saying this is conclusive; just that I could not replicate
> your issue. Generally, it should work, but it may be a Windows thing, it
> could be a C++ thing, it might be a (whatever compiler you used) issue. It
> could be lots of things.
>
> Also, we are all aware that errno got changed recently for compatibility
> reasons with threads. I don't know if tcc has that change or not.

I found the problem. One of the header files contains:

#define errno (*bb_errno)

[Kenny McCormack]

In article <b46f4f9e-909d-4f7a...@googlegroups.com>,

Frederick Virchanza Gotham <cauldwel...@gmail.com> wrote:

So your compiler (still not specified) has a bug, right?

--
Trump - the President for the rest of us.

https://www.youtube.com/watch?v=JSkUJKgdcoE

[Paavo Helde]

11.02.2023 02:06 Frederick Virchanza Gotham kirjutas:
>
> I've run a desktop PC program (x86_64 MS-Windows) through the 'gdb' debugger and I can clearly see that it segfaults when it reads the value of 'errno'.
>
> To try understand what's going on, I wrote a minimal program:
>
> #include <errno.h>
>
> int main(void)
> {
> return errno;
> }
>
> and then I compiled it with "-E -P" to get the preprocessor output:
>
> extern int *__errno_location (void) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__));
>
> int main(void)
> {
> return (*__errno_location ());
> }

All this trickery is there because errno predates threads, and needs
jumping through some hoops nowadays to get it thread-local.

[Frederick Virchanza Gotham]

On Saturday, February 11, 2023 at 3:26:53 AM UTC, Kenny McCormack wrote:
>
> >I found the problem. One of the header files contains:
> >
> > #define errno (*bb_errno)
> So your compiler (still not specified) has a bug, right?

I'm combining three programs together, ssh + tun2socks + route, to create a program that can connect to an SSH server and establish a VPN connection to it, even if you don't have admin rights on the remote server. I took the code for 'route' from busybox, and it references a variable called "bb_errno" which I presume must start out as a nullptr -- I haven't checked yet.

[Kenny McCormack]

In article <79a3567f-71ae-4c7f...@googlegroups.com>,

Frederick Virchanza Gotham <cauldwel...@gmail.com> wrote:

Ah, yes. That makes sense. Now we know what the 'bb' stands for.

By the way, are these programs you are merging written in C or C++?
Just askin'...

--
Republican Congressman Matt Gaetz claims that only ugly women want
abortions, which they will never need since no one will impregnate them.

[David Brown]

It's worth noting that "errno" has always (at least since C90, I
believe) been specified as being allowed to be a macro, precisely so
that implementations can do things like make it thread-local.

[Scott Lurndal]

Frederick Virchanza Gotham <cauldwel...@gmail.com> writes:
>
>I've run a desktop PC program (x86_64 MS-Windows) through the 'gdb' debugger and I can clearly see that it segfaults when it reads the value of 'errno'.
>
>To try understand what's going on, I wrote a minimal program:
>

>int main(void)
>{
> return (*__errno_location ());
>}
>
>So, 'errno' is the dereferencing of the return_value from the invocation of a function.

In a multithreaded application errno must refer to thread-private
data, so that each thread has its own copy of errno (which is a global
variable). To support that, errno is a macro that expands to a
function that returns the address of the thread-specific version of
errno.

If it's invalid, it likely means your application did not correctly
call the functionality to initialize the C or Thread library state;
this normally happens during the C runtime (CRT) support that runs
before the function main in the application is invoked.

[Paavo Helde]

The busybox header which redefines errno contains these claims:

/* Busybox does not use threads [...]
[...] no multithreading in busybox :) */


So good luck with getting it run as a thread in your proposed
multithreaded composite application! The bb_errno trick seems to be just
one of their unneeded premature optimizations, so you should feel at home!

[Frederick Virchanza Gotham]

On Saturday, February 11, 2023 at 8:14:18 PM UTC, Paavo Helde wrote:
>
> The busybox header which redefines errno contains these claims:
>
> /* Busybox does not use threads [...]
> [...] no multithreading in busybox :) */
>
>
> So good luck with getting it run as a thread in your proposed
> multithreaded composite application! The bb_errno trick seems to be just
> one of their unneeded premature optimizations, so you should feel at home!

I already have it working. It creates a TUN device, then connects to the SSH server and starts a local SOCKS server, then sets the IP address of the TUN device and manipulates the routing table, then starts tun2socks.

I have it working, I'm just tweaking it now.