Your mail has nothing to do with the 3.8 release, nor with testing our code, nor with the malloc stuff I posted. You are hijacking yet another thread with your broken code, and it is quite frankly getting boring.
> I am not sure if this is related. But when I code assembly to pass > a double precision floating point value (%xmm0) to printf, my program will > crash > without a stack frame. I am fine for passing strings and integers. > > Here's the simple code: > > .section .data > > str: > .string "%f\n" > test: > .float 2.5 > > .section .text > .extern printf > > .global main > > main: > > push %rbp # set-up stack frame > movq %rsp, %rbp # will fault without this > > movl $str, %edi > movl $test, %eax > cvtss2sd (%rax), %xmm0 > movq $1, %rax > call printf > > movq $1, %rax > xorq %rdi, %rdi > syscall > > > If I remove the stack frame, this code will fault every time. Now, according > to the amd64 ABI, I shouldn't need a stack frame. Now, gcc compiles with > stack > frames, but this does appear to be a memory bug. I'm just not sure where to > go > next to research this further. > > Here's my dmesg: > > OpenBSD 3.8-beta (GENERIC) #210: Sat Aug 13 20:20:15 MDT 2005 > [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1073278976 (1048124K) > avail mem = 909148160 (887840K) > using 22937 buffers containing 107536384 bytes (105016K) of memory > mainbus0 (root) > cpu0 at mainbus0: (uniprocessor) > cpu0: AMD Athlon(tm) 64 Processor 3000+, 1808.55 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line > 16-way L2 cache > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative > pci0 at mainbus0 bus 0: configuration mode 1 > "Nvidia nForce4 DDR" rev 0xa3 at pci0 dev 0 function 0 not configured > "Nvidia nForce4 ISA" rev 0xa3 at pci0 dev 1 function 0 not configured > "Nvidia nForce4 SMBus" rev 0xa2 at pci0 dev 1 function 1 not configured > ohci0 at pci0 dev 2 function 0 "Nvidia nForce4 USB" rev 0xa2: irq 10, version > 1.0, legacy support > usb0 at ohci0: USB revision 1.0 > uhub0 at usb0 > uhub0: Nvidia OHCI root hub, rev 1.00/1.00, addr 1 > uhub0: 10 ports with 10 removable, self powered > ehci0 at pci0 dev 2 function 1 "Nvidia nForce4 USB" rev 0xa3: irq 11 > usb1 at ehci0: USB revision 2.0 > uhub1 at usb1 > uhub1: Nvidia EHCI root hub, rev 2.00/1.00, addr 1 > uhub1: 10 ports with 10 removable, self powered > auich0 at pci0 dev 4 function 0 "Nvidia nForce4 AC97" rev 0xa2: irq 11, > nForce4 > AC97 > ac97: codec id 0x414c4760 (Avance Logic ALC655) > audio0 at auich0 > pciide0 at pci0 dev 6 function 0 "Nvidia nForce4 IDE" rev 0xa2: DMA, channel 0 > configured to compatibility, channel 1 configured to compatibility > pciide0: channel 0 disabled (no drives) > atapiscsi0 at pciide0 channel 1 drive 0 > scsibus0 at atapiscsi0: 2 targets > cd0 at scsibus0 targ 0 lun 0: <HL-DT-ST, DVDRAM GSA-4163B, A103> SCSI0 5/cdrom > removable > cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 > pciide1 at pci0 dev 7 function 0 "Nvidia nForce4 SATA 1" rev 0xa3: DMA > (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI > pciide1: using irq 10 for native-PCI interrupt > wd0 at pciide1 channel 0 drive 0: <WDC WD360GD-00FLA2> > wd0: 16-sector PIO, LBA48, 35304MB, 72303840 sectors > pciide1: channel 1 ignored (not responding; disabled or no drives?) > pciide2 at pci0 dev 8 function 0 "Nvidia nForce4 SATA 2" rev 0xa3: DMA > (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI > pciide2: using irq 11 for native-PCI interrupt > pciide2: channel 0 ignored (not responding; disabled or no drives?) > pciide2: channel 1 ignored (not responding; disabled or no drives?) > ppb0 at pci0 dev 9 function 0 "Nvidia nForce4 PCI-PCI" rev 0xa2 > pci1 at ppb0 bus 1 > vga1 at pci1 dev 5 function 0 "ATI Rage XL" rev 0x27 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > "VIA VT6306 FireWire" rev 0x80 at pci1 dev 6 function 0 not configured > "Nvidia CK804 LAN" rev 0xa3 at pci0 dev 10 function 0 not configured > ppb1 at pci0 dev 11 function 0 "Nvidia nForce4 PCIE" rev 0xa3 > pci2 at ppb1 bus 2 > ppb2 at pci0 dev 12 function 0 "Nvidia nForce4 PCIE" rev 0xa3 > pci3 at ppb2 bus 3 > ppb3 at pci0 dev 13 function 0 "Nvidia nForce4 PCIE" rev 0xa3 > pci4 at ppb3 bus 4 > bge0 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1 > (0x4101): > irq 5 address 00:e0:81:56:8f:66 > brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 > ppb4 at pci0 dev 14 function 0 "Nvidia nForce4 PCIE" rev 0xa3 > pci5 at ppb4 bus 5 > pchb0 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00 > pchb1 at pci0 dev 24 function 1 "AMD AMD64 Address Map" rev 0x00 > pchb2 at pci0 dev 24 function 2 "AMD AMD64 DRAM Cfg" rev 0x00 > pchb3 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00 > isa0 at mainbus0 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo > pckbc0 at isa0 port 0x60/5 > pckbd0 at pckbc0 (kbd slot) > pckbc0: using irq 1 for kbd slot > wskbd0 at pckbd0: console keyboard, using wsdisplay0 > pmsi0 at pckbc0 (aux slot) > pckbc0: using irq 12 for aux slot > wsmouse0 at pmsi0 mux 0 > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > sysbeep0 at pcppi0 > lpt0 at isa0 port 0x378/4 irq 7 > dkcsum: wd0 matches BIOS drive 0x80 > root on wd0a > rootdev=0x0 rrootdev=0x300 rawdev=0x302 > auich0: measured ac97 link rate at 48010 Hz, will use 48000 Hz > > like to ask the community to do lots of testing over the next week if > > they can. > > > > This release will bring a lot of new ideas from us. One of them in > > particular is somewhat risky. I think it is time to talk about that > > one, and let people know what is ahead on our road. > > > > Traditionally, Unix malloc(3) has always just "extended the brk", > > which means extending the traditional Unix process data segment to > > allocate more memory. malloc(3) would simply extend the data segment, > > and then calve off little pieces to requesting callers as needed. It > > also remembered which pieces were which, so that free(3) could do it's > > job. > > > > The way this was always done in Unix has had a number of consequences, > > some of which we wanted to get rid of. In particular, malloc & free > > have not been able to provide strong protection against overflows or > > other corruption. > > > > Our malloc implementation is a lot more resistant (than Linux) to > > "heap overflows in the malloc arena", but we wanted to improve things > > even more. > > > > Starting a few months ago, the following changes were made: > > > > - We made the mmap(2) system call return random memory addresses. As well > > the kernel ensures that two objects are not mapped next to each other; > > in effect, this creates unallocated memory which we call a "guard page". > > > > - We have changed malloc(3) to use mmap(2) instead of extending the data > > segment via brk() > > > > - We also changed free(3) to return memory to the kernel, un-allocating > > them out of the process. > > > > - As before, objects smaller than a page are allocated within shared > > pages that malloc(3) maintains. But their allocation is now somewhat > > randomized as well. > > > > - A number of other similar changes which are too dangerous for normal > > software or cause too much of a slowdown are available as malloc options > > as described in the manual page. These are very powerful for debugging > > buggy applications. > > > > Other results: > > > > - When you free an object that is >= 1 page in size, it is actually > > returned to the system. Attempting to read or write to it after > > you free is no longer acceptable. That memory is unmapped. You get > > a SIGSEGV. > > > > - For a decade and a bit, we have been fixing software for buffer overflows. > > Now we are finding a lot of software that reads before the start of the > > buffer, or reads too far off the end of the buffer. You get a SIGSEGV. > > > > To some of you, this will sound like what the Electric Fence toolkit > > used to be for. But these features are enabled by default. Electric > > Fence was also very slow. It took nearly 3 years to write these > > OpenBSD changes since performance was a serious consideration. (Early > > versions caused a nearly 50% slowdown). > > > > Our changes have tremendous benefits, but until some bugs in external > > packages are found and fixed, there are some risks as well. Some > > software making incorrect assumptions will be running into these new > > security technologies. > > > > I discussed this in talks I have given before: I said that we were > > afraid to go ahead with guard pages, because a lot of software is just > > written to such low standards. Applications over-read memory all the > > time, go 1 byte too far, read 1 byte too early, access memory after free, > > etc etc etc. > > > > Oh well -- we've decided that we will try to ship with this protection > > mechanism in any case, and try to solve the problems as we run into > > them. > > > > Two examples: > > > > Over the last two months, some OpenBSD users noticed that the X server > > was crashing occasionally. Two bugs have been diagnosed and fixed by > > us. One was a use-after-free bug in the X shared library linker. The > > other was a buffer-over-read bug deep down in the very lowest level > > fb* pixmap compositing routines. The latter bug in particular was > > very difficult to diagnose and fix, and is about 10 years old. We > > have found other bugs like this in other external software, and even a > > few in the base OpenBSD tree (though those were found a while back, > > even as we started experimenting with the new malloc code). > > > > I would bet money that the X fb* bug has crashed Linux (and other) X > > servers before. It is just that it was very rare, and noone ever > > chased it. The new malloc we have just makes code get lucky less > > often, which lets us get to the source of a bug easier. As a > > programmer, I appreciate anything which makes bugs easier to > > reproduce. > > > > We expect that our malloc will find more bugs in software, and this > > might hurt our user community in the short term. We know that what > > this new malloc is doing is perfectly legal, but that realistically > > some open source software is of such low quality that it is just not > > ready for these things to happen. > > > > We ask our users to help us uncover and fix more of these bugs in > > applications. Some will even be exploitable. Instead of saying that > > OpenBSD is busted in this regard, please realize that the software > > which is crashing is showing how shoddily it was written. Then help > > us fix it. For everyone.. not just OpenBSD users. > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com
