assembly - What does killed mean, as response to loading a program in Fedora linux? -

i have assembler program simple structure, text segment , bss segment. similar programs have been compiled me on decade. forth compiler , play tricks elf header. i'm used if mess elf header, can't start program , loader says "killed" before segfaults.

but i've user of fedora version 6 linux, following:

as -32 lina.s ld a.out -n -melf_i386 -o lina ./lina 

and message "killed" , 137 result of 'echo $?'

clearly procedure uses official tools, such elf header should @ least valid. exact same procedure on other systems ubuntu or debian systems lead programs work normally. objdumps of resulting programs same @ least mapping of segments concerned.

please give me indication of going on here, have no clue of how tackle problem.

i'd stress no instruction executed, i.e. gdb refuses run it. so

(gdb) run starting program: /home/gerard/desktop/lina-5.1/glina32 warning: cannot insert breakpoint -2. error accessing memory address 0x8048054: input/output error. 

(gdb)

in rare cases if error occurs while when process tries execute new program linux kernel send sigkill signal process instead of returning error. signal result in shell printing "killed", rather more useful error message "out of memory". the executable you've created triggers error kernel can recover killing process tried execute it.

normally shells execute program making 2 system calls: fork , execve. first system call creates new process, doesn't load new executable. instead fork system call duplicates process invoked it. second system call loads new executable doesn't create new process. instead program running in process replaced new program executable.

in process of performing execve system call kernel needs discard previous contents of process's address space can replace entirely new one. after point execve system call can no longer return error code program invoked program no longer exists. if error occurs after point prevents executable loading kernel has no other option kill process.

this behaviour documented in linux execve(2) man page:

in cases execve() fails, control returns original executable image, , caller of execve() can handle error. however, in (rare) cases (typically caused resource exhaustion), failure may occur past point of no return: original executable image has been torn down, new image not built. in such cases, kernel kills process sigkill signal.