Why is my nasm program killing itself?
in [ASM]
|
Prev: Sudoku
Next: Linux distro request
From: ivanatora on 3 Apr 2008 15:38 Frank, I've tried that source on several machines and it gets killed on both of them. These include kernel versions: 2.6.23.9 2.6.21.5 2.6.12.4 I've tried your code and it runs perfect. I even replaced mov eax, 1 with mov al,1 and it still works. I removed nops and it works. Removed even the .data section and it works. I've moved back to my code and tried something else. I removed the .bss section and the program didn't get killed! So mov al,1 is working at all :) I replaced the .bss section with: section .data x db 0x1 and the program is not getting killed. Now I'm loading AL or AX or EAX, even doing division :) Btw, how can I see the contents of a variable in gdb? I can see registers with "info registers", but I want to see what x is look like.
From: Herbert Kleebauer on 3 Apr 2008 17:37 ivanatora wrote: > > Frank, I've tried that source on several machines and it gets killed > on both of them. These include kernel versions: > 2.6.23.9 > 2.6.21.5 > 2.6.12.4 Can you post a download link to this binary. Or post a hex dump here.
From: Frank Kotler on 3 Apr 2008 18:10 ivanatora wrote: > Frank, I've tried that source on several machines and it gets killed > on both of them. These include kernel versions: > 2.6.23.9 > 2.6.21.5 > 2.6.12.4 Oh, oh! > I've tried your code and it runs perfect. I even replaced mov eax, 1 > with mov al,1 and it still works. I removed nops and it works. Removed > even the .data section and it works. > I've moved back to my code and tried something else. I removed > the .bss section and the program didn't get killed! > So mov al,1 is working at all :) > I replaced the .bss section with: > section .data > x db 0x1 > and the program is not getting killed. Stranger and stranger! Your original code had a variable in .bss, and you could write to it once, but not twice, right? So it isn't an "absolute prohibition" on .bss. In that case, the size of .bss didn't change, but its position did, and alignment(?). Default alignment for ..bss is 4 - might try "section .bss align=16" or 64, or even 4096. I like "trial and error", but this is ridiculous! The answer's in the source, somewhere... I've advised the "nasm-users" list at SF about this. I'll cc this to 'em, just to update 'em on the kernel versions. I was hoping this was a "one time" deal, but I guess not... I'm completely baffled! > Now I'm loading AL or AX or EAX, even doing division :) > Btw, how can I see the contents of a variable in gdb? I can see > registers with "info registers", but I want to see what x is look like. (assemble with the "-g" switch!) "print x", apparently. (printf, too, apparently, but it's complaining about my format string having a missing '"'!) You might be interseted in this: http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php And/or: http://linuxfocus.berlios.de/English/July2004/article343.shtml (thanks again, Nathan!) Besides "man gdb" and "info gdb", a google for "gdb tutorial" finds a flock of 'em. If you *really* want to get into gdb: http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php But I don't think gdb is going to help with this problem(?). Best, Frank
From: Chuck Crayne on 3 Apr 2008 22:43 On Thu, 03 Apr 2008 22:10:26 GMT Frank Kotler <fbkotler(a)verizon.net> wrote: > Stranger and stranger! Your original code had a variable in .bss, and > you could write to it once, but not twice, right? This is a description of the intent of the program, and has little or nothing to do with the actual problem, which is that programs with a .bss segment of a certain size and/or alignment trigger an error in certain versions of the Linux ELF loader, which has since been fixed. From our past experience, it seems likely that this kernel bug involves clearing the remainder of the physical page which contains the .bss segment. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Frank Kotler on 4 Apr 2008 16:51
Chuck Crayne wrote: > On Thu, 03 Apr 2008 22:10:26 GMT > Frank Kotler <fbkotler(a)verizon.net> wrote: > > >>Stranger and stranger! Your original code had a variable in .bss, and >>you could write to it once, but not twice, right? > > > This is a description of the intent of the program, and has little or > nothing to do with the actual problem, which is that programs with > a .bss segment of a certain size and/or alignment trigger an > error in certain versions of the Linux ELF loader, Right. My "point" in mentioning it is that it "points" to something other than "size"... > which has since > been fixed. Okay. > From our past experience, it seems likely that this kernel > bug involves clearing the remainder of the physical page which contains > the .bss segment. That's what it sounds like to me... Looking at 2.6.23.9, I see: .... if (unlikely (elf_brk > elf_bss)) { unsigned long nbyte; /* There was a PT_LOAD segment with p_memsz > p_filesz before this one. Map anonymous pages, if needed, and clear the area. */ retval = set_brk (elf_bss + load_bias, elf_brk + load_bias); if (retval) { send_sig(SIGKILL, current, 0); goto out_free_dentry; } .... There are a number of places where we could be killed... this one attracts me because it appears to involve ".bss". Haven't chased down what "unlikely" does, nor "set_brk". The latter presumably zeros the page(?)... I don't know if that's the right "kill", or what the workaround is for Ivan to avoid it... besides eliminating .bss altogether, or upgrading the kernel. I noticed another one I'm "suspicious" of, in "the other weirdness": .... retval = -ENOEXEC; /* First of all, some simple consistency checks */ if (memcmp(loc->elf_ex.e_ident, ELFMAG, SELFMAG) != 0) goto out; if (loc->elf_ex.e_type != ET_EXEC && loc->elf_ex.e_type != ET_DYN) goto out; if (!elf_check_arch(&loc->elf_ex)) goto out; if (!bprm->file->f_op||!bprm->file->f_op->mmap) goto out; /* Now read in all of the header information */ if (loc->elf_ex.e_phentsize != sizeof(struct elf_phdr)) goto out; .... "out:" just returns ret_val. Possibly why this kernel's giving "can't execute binary file" for "Herbert's version"??? That's as close as I've gotten to becoming a "kernel guru"... probably neither of 'em is right... Best, Frank |