I happened upon a user here that posted a couple of months ago(I think) who used IRIX and had successfully compiled stunnel. Any chance you're still around!?!?
I get one of two things. Before I apply the patch, it will crash right after startup. No logs, just dumps core. After the patch, it starts and exits immediately. I can run it with -version, etc. and it seems to work fine.
Anyone had this and/or know what can be done?
Eric
"Eric Haddix" burnout@stdio.com wrote:
I happened upon a user here that posted a couple of months ago(I think) who used IRIX and had successfully compiled stunnel. Any chance you're still around!?!?
I get one of two things. Before I apply the patch, it will crash right after startup. No logs, just dumps core. After the patch, it starts and exits immediately. I can run it with -version, etc. and it seems to work fine.
Anyone had this and/or know what can be done?
I can implement compatibility fixes on any Unix system. I just need a shell account for testing. 8-)
Best regards, Mike
Michal Trojnara wrote:
I can implement compatibility fixes on any Unix system. I just need a shell account for testing. 8-)
I might offer you that soon as I'm losing my mind trying to get this working.
Here's a backtrace..
This GDB was configured as "mips-sgi-irix6.5"... Core was generated by `stunnel'. Program terminated with signal 10, Bus error. Reading symbols from /usr/freeware/lib32/libz.so...done. Loaded symbols for /usr/freeware/lib32/libz.so Reading symbols from /usr/lib32/libsocket.so...done. Loaded symbols for /usr/lib32/libsocket.so Reading symbols from /usr/lib32/libnsl.so...done. Loaded symbols for /usr/lib32/libnsl.so Reading symbols from /usr/freeware/lib32/libwrap.so.7...done. Loaded symbols for /usr/freeware/lib32/libwrap.so.7 Reading symbols from /usr/lib32/libc.so.1...done. Loaded symbols for /usr/lib32/libc.so.1 #0 0x1002a780 in client (arg=0x7) at client.c:106 106 s_log(LOG_DEBUG, "%s started", c->opt->servname); (gdb) backtrace full #0 0x1002a780 in client (arg=0x7) at client.c:106 c = (CLI *) 0x101a1b58
Here's my setup(I'm not certain I understand all of your bug reporting procedure since some of them are apparently 3.x specific and don't give me anything)
I'm using it as standalone.
stunnel -version reports:
stunnel 4.12 on mips-sgi-irix6.5 UCONTEXT+POLL+IPv4+LIBWRAP with OpenSSL 0.9.8a 11 Oct 2005
Global options cert = /usr/local/etc/stunnel/stunnel.pem ciphers = ALL:!ADH:+RC4:@STRENGTH debug = 5 key = /usr/local/etc/stunnel/stunnel.pem pid = /usr/local/var/run/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes session = 300 seconds verify = none
Service-level options TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds
stunnel.conf: # start CAfile=ca.pem cert=stunnel.pem key=server.key client=no foreground=yes verify=0 [psuedo-https] accept=443 connect=8081 TIMEOUTclose=0
uname -a: IRIX64 octagon 6.5 10070055 IP30
gcc -v: Reading specs from /usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3/specs Configured with: ../configure --prefix=/usr/freeware --enable-version-specific-runtime-libs --disable-shared --enable-threads --enable-haifa --enable-libgcj --disable-c-mbchar Thread model: single gcc version 3.3
"Eric Haddix" burnout@stdio.com wrote:
I might offer you that soon as I'm losing my mind trying to get this working.
[cut]
#0 0x1002a780 in client (arg=0x7) at client.c:106 106 s_log(LOG_DEBUG, "%s started", c->opt->servname); (gdb) backtrace full #0 0x1002a780 in client (arg=0x7) at client.c:106 c = (CLI *) 0x101a1b58
[cut]
stunnel 4.12 on mips-sgi-irix6.5 UCONTEXT+POLL+IPv4+LIBWRAP with OpenSSL 0.9.8a 11 Oct 2005
I'd try: ./configure --with-threads=fork make clean make make install
It could be the same bug in ucontext as in old Solaris.
Best regards, Mike
Michal Trojnara wrote:
I'd try: ./configure --with-threads=fork make clean make make install
It could be the same bug in ucontext as in old Solaris.
Hi Michal,
Thanks. That did it!! I had to apply that patch that Greg Matt had offered a while back but it works!! I can now actually get to developing my software again, a feeling I'm sure you understand..:)
Thanks again for your help!!
Eric
Eric Haddix wrote:
#0 0x1002a780 in client (arg=0x7) at client.c:106 106 s_log(LOG_DEBUG, "%s started", c->opt->servname);
I have just seen a crash at a similar place on x86_64. The apparent cause is sthreads.c:116: makecontext(&ctx->ctx, (void(*)(void))cli, 1, arg); arg is a void *, but: - the size is given as 1; it should be (sizeof (arg) + sizeof (int) - 1) / sizeof (int) because the "size" is defined as a number of int arguments - it won't work anyway; makecontext () is defined to work only for integer parameters. It is not possible to pass a pointer as integers on x86_64, which uses registers to pass the first 6 integer or pointer parameters.
--with-threads=pthread seems to work fine in my test case. Mirek
Miloslav Trmac wrote:
I have just seen a crash at a similar place on x86_64. The apparent cause is sthreads.c:116: makecontext(&ctx->ctx, (void(*)(void))cli, 1, arg); arg is a void *, but:
- the size is given as 1; it should be (sizeof (arg) + sizeof (int) - 1) / sizeof (int) because the "size" is defined as a number of int arguments
- it won't work anyway; makecontext () is defined to work only for integer parameters. It is not possible to pass a pointer as integers on x86_64, which uses registers to pass the first 6 integer or pointer parameters.
Are we still talking about IRIX? http://nixdoc.net/man-pages/IRIX/man3c/makecontext.3c.html I can't find any of mentioned limitations in the manual. Just the opposite: "the arguments that follow the argc parameter for makecontext are restricted to longs and pointers only".
Best regards, Mike
Michal Trojnara wrote:
Are we still talking about IRIX?
Sorry, I was talking about Linux and forgot to say that.
The SUSv3 (POSIX) specification is at http://www.opengroup.org/onlinepubs/009695399/functions/makecontext.html:
The application shall ensure that the value of argc matches the number of arguments of type int passed to func; otherwise, the behavior is undefined.
BTW, makecontext () is now marked obsolectent by POSIX. While it probably works well on several platfoms and operating systems, maybe it should not be the default any more... Mirek
Miloslav Trmac wrote:
The application shall ensure that the value of argc matches the number of arguments of type int passed to func; otherwise, the behavior is undefined.
You're right about the type of arguments. "IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/33 is applied, clarifying that the arguments passed to func are of type int."
What about the number of arguments? Why isn't "1" correct?
BTW, makecontext () is now marked obsolectent by POSIX. While it probably works well on several platfoms and operating systems, maybe it should not be the default any more...
I'll think about it.
Mike
Michal Trojnara wrote:
What about the number of arguments? Why isn't "1" correct?
Assume the traditional way of passing arguments on stack, with "int" naturally aligned. Then makecontext does something like this: - set stack pointer to "top" - argc * sizeof(int) - copy argc * sizeof (int) bytes from makecontext() arguments to stack - set up the rest of the frame
If sizeof (void *) > sizeof (int), which happens on 64-bit platforms, the above doesn't copy the whole value of the pointer when argc == 1. Mirek
Miloslav Trmac wrote:
What about the number of arguments? Why isn't "1" correct?
Assume the traditional way of passing arguments on stack, with "int" naturally aligned. Then makecontext does something like this:
- set stack pointer to "top" - argc * sizeof(int)
- copy argc * sizeof (int) bytes from makecontext() arguments to stack
- set up the rest of the frame
If sizeof (void *) > sizeof (int), which happens on 64-bit platforms, the above doesn't copy the whole value of the pointer when argc == 1.
As you saw IRIX used just opposite default (pointer/long).
It seemed reasonable to me to align parameters to 8 byte baundary on 64-bit machines...
I decided to change the default threading model. Ucontext creates quite a lot of portability issues.
Best regards, Mike
-
Eric Haddix -
Michal Trojnara -
Miloslav Trmac