Re: OpenBSD upgrade guide 5.2?
On 10/19/12 23:25, Matt Morrow wrote: > Does anyone know when the upgrade guides are usually posted? I know we're a > couple of weeks away from the release, but I also thought I read that 5.2 > cds had already been shipped to some locations, which would imply that it's > pretty much ready for release? I figured I'd take some time to look over it > ahead of time. > usually, posted somewhat earlier than this. :-/ I hope to have upgrade52.html done and committed Very Soon. Nick.
sigaltstack and siglongjmp
Hello.
I want to catch stack overflow exceptions in my program.
I use sigaltstack to set up alternate stack on which SIGSEGV signals should
processed, and siglongjmp from signal handler to jump to restore point.
But in this case signal handler executes on alternate stack only once.
In next times signal handler executes on main program stack.
There is test program:
#include
#include
#include
#include
#include
#include
#include
#include
static sigjmp_buf loop;
static int n = 0; /* SIGSEGV counter */
static void *mainStack;
static void TrapHandler (int sig, siginfo_t *sip, void *scp)
{
printf("[ segmentation violation\n");
printf(" TrapHandler stack: %p (", &sig);
if ((unsigned long int)(mainStack) - (unsigned long int)(&sig) > 1000) {
printf("not ");
}
printf("near main stack) ]\n");
if (n == 5) {
exit(100); /* too many segmentation faults */
} else {
++n;
siglongjmp(loop, 1);
}
}
static int InstallSigSegV ()
{
int res;
struct sigaltstack sigstk;
struct sigaction sa;
sigstk.ss_sp = malloc(SIGSTKSZ);
if (sigstk.ss_sp != NULL) {
sigstk.ss_size = SIGSTKSZ;
sigstk.ss_flags = 0;
res = sigaltstack(&sigstk, 0);
if (res == 0) {
sa.sa_sigaction = &TrapHandler;
sigfillset(&sa.sa_mask);
sa.sa_flags = SA_SIGINFO | SA_ONSTACK;
res = sigaction(SIGSEGV, &sa, NULL);
if (res != 0) {
assert(res == -1);
printf("InstallSigSegV: sigaction(SIGSEGV):
%s\n", strerror(errno));
res = 3;
}
} else {
assert(res == -1);
printf("InstallSigSegV: sigaltstack(%d B): %s\n",
SIGSTKSZ, strerror(errno));
res = 2;
}
} else {
printf("InstallSigSegV: malloc(%d B) failed\n", SIGSTKSZ);
res = 1;
}
return res;
}
static void StackOverflow ()
{
volatile char c[10240];
c[0] = 0;
StackOverflow();
c[0] = 1;
}
static void InvalidMemoryAccess ()
{
int *x = 0;
*x = 0;
}
static void P ()
{
if (n % 2 != 0) {
InvalidMemoryAccess();
} else {
StackOverflow();
}
}
int main (int argc, char *argv[])
{
int res;
mainStack = &res;
printf("main stack: %p\n", mainStack);
res = InstallSigSegV();
if (res == 0)
{
res = sigsetjmp(loop, 1);
assert((res == 0) || (res == 1));
printf("start...\n");
P();
printf("...all done\n");
}
return res;
}
There is output (OpenBSD 5.2 / i386):
$ ./test1
main stack: 0xcfbc1c30
start...
[ segmentation violation
TrapHandler stack: 0x83ac9f1c (not near main stack) ]
start...
[ segmentation violation
TrapHandler stack: 0xcfbc1b1c (near main stack) ]
start...
Illegal instruction (core dumped)
Fedora Core 17 / i386:
$ ./test1
main stack: 0xbf95b84c
start...
[ segmentation violation
TrapHandler stack: 0x9e7ef00 (not near main stack) ]
start...
[ segmentation violation
TrapHandler stack: 0x9e7ef00 (not near main stack) ]
start...
[ segmentation violation
TrapHandler stack: 0x9e7ef00 (not near main stack) ]
start...
[ segmentation violation
TrapHandler stack: 0x9e7ef00 (not near main stack) ]
start...
[ segmentation violation
TrapHandler stack: 0x9e7ef00 (not near main stack) ]
start...
[ segmentation violation
TrapHandler stack: 0x9e7ef00 (not near main stack) ]
This is error in OpenBSD or I should use other method to catch stack overflow
exceptions?
Thank you in advance for your answers.
Best regards, Alexander.
[demime 1.01d removed an attachment of type application/octet-stream which had
a name of test1.c]
Re: ttyV0 on sparc64 without vcc(4)?
On Sat, Oct 20, 2012 at 01:55:07AM -0500, J Sisson wrote:
> I was reading:
>
> http://www.openbsd.org/papers/eurobsdcon2011-kettenis.pdf
>
> and noted the section about vcc. I read the vcc man page, and saw FILES
> /dev/ttyV[0-9a-zA-Z]. Looking at an Ultra5, I noted that ttyV0 existed
> (fresh install of latest snapshot + build of -CURRENT checked out
> yesterday). I realize the Ultra5 (400 MHz UltraSparc IIi) is not a
> T1/2...but I couldn't resist running the following to see what it would do
> (non production machine, so if it breaks anything no worries):
>
> cu -l ttyV0
>
> It immediately panic'd the machine. I grabbed trace/ps from the panic
> (dmesg at bottom):
This is a bug. Please report to bugs@
-Otto
>
> # cu -l ttyV0
> panic: kernel data fault: pc=150db04 addr=0
> kdb breakpoint at 146d380
> Stopped at Debugger+0x4: nop
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb> trace
> data_access_fault(40008dfd600, 30, 150db04, 0, 0, 800809) at
> data_access_fault+
> 0x294
> trapbase_sun4v(0, 0, 0, 0, 0, 40008dfdc70) at trapbase_sun4v+0x8790
> VOP_UNLOCK(7f00, 7, 2000, 40004899d40, 40004882805, 20c044) at
> VOP_UNLOCK+0x20
> spec_open(181fcc0, 2180, 0, 0, 80, 400048ac500) at spec_open+0x270
> VOP_OPEN(40004787b30, 7, 400048ac500, 40004899d40, 1, 40008dfd980) at
> VOP_OPEN+
> 0x24
> vn_open(0, 7, 40004787b30, 93b8b03454, 0, 85) at vn_open+0x110
> doopenat(0, ff9c, 0, 7, 40, 40008dfde00) at doopenat+0xb0
> syscall(40008dfded0, 405, 93b5705a38, 93b5705a3c, 0, 91afc0d230) at
> syscall+0x3
> 18
> softtrap(93b1aed5a0, 6, 40, 91b000f0e0, 0, 93b0f78000) at softtrap+0x19c
> ddb> ps
>PID PPID PGRPUID S FLAGS WAIT COMMAND
> *27403 26124 27403 0 7 0cu
> 26124 1 26124 0 30x88 pause ksh
> 30887 1 30887 0 30x80 selectcron
> 12040 1 12040 99 30x80 poll sndiod
> 9978 1 9978 0 30x80 selectinetd
> 1775 1 1775 0 30x80 selectsendmail
> 4950 1 4950 0 30x80 selectsshd
> 15327 26460 13216 83 30x80 poll ntpd
> 26460 13216 13216 83 30x80 poll ntpd
> 13216 1 13216 0 30x80 poll ntpd
> 11569 31544 31544 74 30x80 bpf pflogd
> 31544 1 31544 0 30x80 netio pflogd
> 18240 8831 8831 73 30x80 poll syslogd
> 8831 1 8831 0 30x80 netio syslogd
> 27203 1 27203 77 30x80 poll dhclient
> 27706 1 9832 0 30x80 poll dhclient
> 11 0 0 0 30x100200 aiodoned aiodoned
> 10 0 0 0 30x100200 syncerupdate
> 9 0 0 0 30x100200 cleaner cleaner
> 8 0 0 0 30x100200 reaperreaper
> 7 0 0 0 30x100200 pgdaemon pagedaemon
> 6 0 0 0 30x100200 bored crypto
> 5 0 0 0 30x100200 pftm pfpurge
> 4 0 0 0 30x100200 bored syswq
> 3 0 0 0 3 0x40100200idle0
> 2 0 0 0 30x100200 kmalloc kmthread
> 1 0 1 0 30x80 wait init
> 0 -1 0 0 3 0x200 scheduler swapper
>
>
> I guess the real question I have is: what purpose does ttyV0 serve on an
> Ultra5 if not for the vcc driver (that the Ultra5 doesn't support?)? Have
> I missed something, or do I need to go back to RTFM some more? A cursory
> grepping through /usr/src for ttyV shows etc/etc.sparc64/MAKEDEV{,.md},
> which doesn't appear to check for vcc before creating ttyV*.
>
>
> dmesg:
>
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
> Copyright (c) 1995-2012 OpenBSD. All rights reserved.
> http://www.OpenBSD.org
>
> OpenBSD 5.2-current (GENERIC) #1: Thu Oct 18 20:37:09 CDT 2012
> root@:/usr/src/sys/arch/sparc64/compile/GENERIC
> real mem = 268435456 (256MB)
> avail mem = 251494400 (239MB)
> mainbus0 at root: Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 400MHz)
> cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 400 MHz
> cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 2048K external
> (64 b/l)
> psycho0 at mainbus0 addr 0xfffc4000: SUNW,sabre, impl 0, version 0, ign 7c0
> psycho0: bus range 0-2, PCI bus 0
> psycho0: dvma map c000-dfff
> pci0 at psycho0
> ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x13
> pci1 at ppb0 bus 1
> ebus0 at pci1 dev 1 function 0 "Sun PCIO EBus2" rev 0x01
>
