* Re: SegFault
@ 2002-06-26 1:56 Stas Sergeev
2002-06-26 3:11 ` SegFault Dan Egli
2002-06-26 3:14 ` SegFault Dan Egli
0 siblings, 2 replies; 22+ messages in thread
From: Stas Sergeev @ 2002-06-26 1:56 UTC (permalink / raw)
To: Dan Egli
Hello.
Dan Egli wrote:
> DosEMU Ver (as reported by RPM) 1.1.1-3
And dosemu says to you at startup:
"Please test against a recent version before reporting bugs and problems."
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: SegFault 2002-06-26 1:56 SegFault Stas Sergeev @ 2002-06-26 3:11 ` Dan Egli 2002-06-26 3:14 ` SegFault Dan Egli 1 sibling, 0 replies; 22+ messages in thread From: Dan Egli @ 2002-06-26 3:11 UTC (permalink / raw) To: stas.orel; +Cc: linux-msdos What's more recent? the most recent "stable" release is 1.0.2! I can always compile the latest dev release, 1.1.3, .. I'll try that, but I'm doubtful ----- Original Message ----- From: "Stas Sergeev" <stssppnn@yahoo.com> To: "Dan Egli" <dan@shortcircuit.dyndns.org> Sent: Tuesday, June 25, 2002 7:56 PM Subject: Re: SegFault > Hello. > > Dan Egli wrote: > > DosEMU Ver (as reported by RPM) 1.1.1-3 > And dosemu says to you at startup: > "Please test against a recent version before reporting bugs and problems." > > - > To unsubscribe from this list: send the line "unsubscribe linux-msdos" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: SegFault 2002-06-26 1:56 SegFault Stas Sergeev 2002-06-26 3:11 ` SegFault Dan Egli @ 2002-06-26 3:14 ` Dan Egli 1 sibling, 0 replies; 22+ messages in thread From: Dan Egli @ 2002-06-26 3:14 UTC (permalink / raw) To: stas.orel; +Cc: linux-msdos Only difference is that the long error message has vanished, replaced by: ERROR: general protection at 0x171ff: 73 ERROR: SIGSEGV, protected insn...exiting! Same diff, Segfaults! ----- Original Message ----- From: "Stas Sergeev" <stssppnn@yahoo.com> To: "Dan Egli" <dan@shortcircuit.dyndns.org> Sent: Tuesday, June 25, 2002 7:56 PM Subject: Re: SegFault > Hello. > > Dan Egli wrote: > > DosEMU Ver (as reported by RPM) 1.1.1-3 > And dosemu says to you at startup: > "Please test against a recent version before reporting bugs and problems." > > - > To unsubscribe from this list: send the line "unsubscribe linux-msdos" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Segfault @ 2017-12-29 9:04 Andrew Tsykhonya 2017-12-31 8:59 ` Segfault Eric Sunshine 0 siblings, 1 reply; 22+ messages in thread From: Andrew Tsykhonya @ 2017-12-29 9:04 UTC (permalink / raw) To: git git stash pop resulted in crash: /usr/local/Cellar/git/2.10.2/libexec/git-core/git-stash: line 470: 14946 Segmentation fault: 11 git merge-recursive $b_tree -- $c_tree $w_tree although, the changes have been applied successfully. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Segfault 2017-12-29 9:04 Segfault Andrew Tsykhonya @ 2017-12-31 8:59 ` Eric Sunshine 2018-01-02 10:11 ` Segfault Andrew Tsykhonya 0 siblings, 1 reply; 22+ messages in thread From: Eric Sunshine @ 2017-12-31 8:59 UTC (permalink / raw) To: Andrew Tsykhonya; +Cc: Git List On Fri, Dec 29, 2017 at 4:04 AM, Andrew Tsykhonya <andrew.tsykhonya@gmail.com> wrote: > git stash pop resulted in crash: > /usr/local/Cellar/git/2.10.2/libexec/git-core/git-stash: line 470: > 14946 Segmentation fault: 11 git merge-recursive $b_tree -- $c_tree > $w_tree > although, the changes have been applied successfully. Thanks for the problem report. Can you come up with a reproduction recipe in order to help debug the problem? Also, what happens if you update to a newer version of Git? You appear to be running 2.10.2, whereas the latest version in Homebrew seems to be 2.15.1. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Segfault 2017-12-31 8:59 ` Segfault Eric Sunshine @ 2018-01-02 10:11 ` Andrew Tsykhonya 0 siblings, 0 replies; 22+ messages in thread From: Andrew Tsykhonya @ 2018-01-02 10:11 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List I made: $git stash $git checkout <branch_name> $git stash pop - crash here. changes were applied, but index.lock was not removed. The issue appeared only once, I haven't seen it before and cannot reproduce it now. Thanks, updated git to 2.15.1. 2017-12-31 10:59 GMT+02:00 Eric Sunshine <sunshine@sunshineco.com>: > On Fri, Dec 29, 2017 at 4:04 AM, Andrew Tsykhonya > <andrew.tsykhonya@gmail.com> wrote: >> git stash pop resulted in crash: >> /usr/local/Cellar/git/2.10.2/libexec/git-core/git-stash: line 470: >> 14946 Segmentation fault: 11 git merge-recursive $b_tree -- $c_tree >> $w_tree >> although, the changes have been applied successfully. > > Thanks for the problem report. Can you come up with a reproduction > recipe in order to help debug the problem? > > Also, what happens if you update to a newer version of Git? You appear > to be running 2.10.2, whereas the latest version in Homebrew seems to > be 2.15.1. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Segfault @ 2010-01-19 21:40 Robert Wimmer 2010-01-20 10:34 ` Segfault RW 0 siblings, 1 reply; 22+ messages in thread From: Robert Wimmer @ 2010-01-19 21:40 UTC (permalink / raw) To: kvm Hi, I'm running Gentoo x86_64 with kernel 2.6.32 and Qemu/KVM 0.12.1.2. Ran fine for about 10 days until today the qemu-system_x86_64 process crashed with a segfault (: Jan 19 06:24:42 scotty kernel: [977458.908149] qemu-system-x86[8920]: segfault at 7f04daab8530 ip 000000000047a614 sp 00007ffff65b1150 error 4 in qemu-system-x86_64[400000+213000] Now the image seems to be corrupt. I can't start the image anymore. It takes a few second and I get the next segfault. Other images running fine with the same parameters. The startup parameters are: /usr/bin/qemu-system-x86_64 --enable-kvm -m 512 -smp 2 -cpu host -daemonize -k de -vnc 127.0.0.1:1 - monitor telnet:10.0.0.8:4444,server,nowait -localtime -pidfile /tmp/kvm-nweb.pid -drive file=/opt/kvm/images/nweb.img,if=virtio,cache=none,boot=on -net nic,vlan=0,model=virtio,macaddr=98:84:44:78:12:aa -net tap,vlan=0,ifname=tap.b.nweb,script=no When I try to convert the image to another format with qemu-img convert -f qcow2 -O raw source.img dest.img I also get segfault's: [1033227.955659] qemu-img[9990]: segfault at 7fd55eb48000 ip 000000000041a2d2 sp 00007fffc1a34fe0 error 7 in qemu-img[400000+32000] [1033236.379335] qemu-img[9991]: segfault at 7fd06332b000 ip 000000000041a2d2 sp 00007fff38eb5a90 error 7 in qemu-img[400000+32000] Is there any chance to get (some) data in the image back? Backup is a few weeks old :-( Thanks! Robert ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Segfault 2010-01-19 21:40 Segfault Robert Wimmer @ 2010-01-20 10:34 ` RW [not found] ` <229432dd1001220635t5ba74dah982d5e5862035a0@mail.gmail.com> 0 siblings, 1 reply; 22+ messages in thread From: RW @ 2010-01-20 10:34 UTC (permalink / raw) To: kvm When I start qemu-img with strace I get the output below. Does this help to to identify the problem? scotty images # strace qemu-img convert -f qcow2 nweb.img -O raw test.img execve("/usr/bin/qemu-img", ["qemu-img", "convert", "-f", "qcow2", "nweb.img", "-O", "raw", "test.img"], [/* 44 vars */]) = 0 brk(0) = 0x635000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec61a000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec619000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/x86_64/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls/x86_64", 0x7fffff9a4cd0) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls", {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0 open("/usr/lib64/x86_64/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/x86_64", 0x7fffff9a4cd0) = -1 ENOENT (No such file or directory) open("/usr/lib64/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=147456, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=207105, ...}) = 0 mmap(NULL, 207105, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc6ec5e6000 close(3) = 0 open("/lib/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\"\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=35656, ...}) = 0 mmap(NULL, 2132976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ec1f6000 mprotect(0x7fc6ec1fe000, 2093056, PROT_NONE) = 0 mmap(0x7fc6ec3fd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7fc6ec3fd000 close(3) = 0 open("/usr/lib64/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340W\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=132454, ...}) = 0 mmap(NULL, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ebfdb000 mprotect(0x7fc6ebff1000, 2093056, PROT_NONE) = 0 mmap(0x7fc6ec1f0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7fc6ec1f0000 mmap(0x7fc6ec1f2000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec1f2000 close(3) = 0 open("/usr/lib64/tls/libaio.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libaio.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\6\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=5280, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5e5000 mmap(NULL, 2101296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ebdd9000 mprotect(0x7fc6ebdda000, 2093056, PROT_NONE) = 0 mmap(0x7fc6ebfd9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fc6ebfd9000 close(3) = 0 open("/usr/lib64/tls/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0 \0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=84272, ...}) = 0 mmap(NULL, 2179568, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ebbc4000 mprotect(0x7fc6ebbd8000, 2093056, PROT_NONE) = 0 mmap(0x7fc6ebdd7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x7fc6ebdd7000 close(3) = 0 open("/usr/lib64/tls/libcurl.so.4", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libcurl.so.4", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\310\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=279672, ...}) = 0 mmap(NULL, 2375624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6eb980000 mprotect(0x7fc6eb9c2000, 2097152, PROT_NONE) = 0 mmap(0x7fc6ebbc2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x42000) = 0x7fc6ebbc2000 close(3) = 0 open("/usr/lib64/tls/libgssapi_krb5.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libgssapi_krb5.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0j\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=173272, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5e4000 mmap(NULL, 2268688, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6eb756000 mprotect(0x7fc6eb77e000, 2097152, PROT_NONE) = 0 mmap(0x7fc6eb97e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7fc6eb97e000 close(3) = 0 open("/usr/lib64/tls/libkrb5.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libkrb5.so.3", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \235\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=602240, ...}) = 0 mmap(NULL, 2697616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6eb4c3000 mprotect(0x7fc6eb551000, 2097152, PROT_NONE) = 0 mmap(0x7fc6eb751000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8e000) = 0x7fc6eb751000 close(3) = 0 open("/usr/lib64/tls/libk5crypto.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libk5crypto.so.3", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20`\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=150360, ...}) = 0 mmap(NULL, 2246760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6eb29e000 mprotect(0x7fc6eb2c1000, 2093056, PROT_NONE) = 0 mmap(0x7fc6eb4c0000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7fc6eb4c0000 close(3) = 0 open("/usr/lib64/tls/libcom_err.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libcom_err.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libcom_err.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\25\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=14440, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5e3000 mmap(NULL, 2109840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6eb09a000 mprotect(0x7fc6eb09d000, 2093056, PROT_NONE) = 0 mmap(0x7fc6eb29c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fc6eb29c000 close(3) = 0 open("/usr/lib64/tls/libresolv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libresolv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\3208\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=80528, ...}) = 0 mmap(NULL, 2185864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6eae84000 mprotect(0x7fc6eae97000, 2093056, PROT_NONE) = 0 mmap(0x7fc6eb096000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12000) = 0x7fc6eb096000 mmap(0x7fc6eb098000, 6792, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc6eb098000 close(3) = 0 open("/usr/lib64/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\r\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=14512, ...}) = 0 mmap(NULL, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6eac80000 mprotect(0x7fc6eac82000, 2097152, PROT_NONE) = 0 mmap(0x7fc6eae82000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fc6eae82000 close(3) = 0 open("/usr/lib64/tls/libgnutls.so.26", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libgnutls.so.26", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\206\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=640744, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5e2000 mmap(NULL, 2736104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ea9e4000 mprotect(0x7fc6eaa79000, 2097152, PROT_NONE) = 0 mmap(0x7fc6eac79000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x95000) = 0x7fc6eac79000 close(3) = 0 open("/usr/lib64/tls/libvdeplug.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libvdeplug.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\34\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=18920, ...}) = 0 mmap(NULL, 2114216, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ea7df000 mprotect(0x7fc6ea7e3000, 2093056, PROT_NONE) = 0 mmap(0x7fc6ea9e2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fc6ea9e2000 close(3) = 0 open("/usr/lib64/tls/libuuid.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libuuid.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libuuid.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\25\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=18824, ...}) = 0 mmap(NULL, 2113920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ea5da000 mprotect(0x7fc6ea5dd000, 2097152, PROT_NONE) = 0 mmap(0x7fc6ea7dd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fc6ea7dd000 close(3) = 0 open("/usr/lib64/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\346\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1371312, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5e1000 mmap(NULL, 3478168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ea288000 mprotect(0x7fc6ea3d1000, 2093056, PROT_NONE) = 0 mmap(0x7fc6ea5d0000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x148000) = 0x7fc6ea5d0000 mmap(0x7fc6ea5d5000, 17048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc6ea5d5000 close(3) = 0 open("/usr/lib64/tls/libtasn1.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libtasn1.so.3", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\36\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=63736, ...}) = 0 mmap(NULL, 2159464, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6ea078000 mprotect(0x7fc6ea087000, 2093056, PROT_NONE) = 0 mmap(0x7fc6ea286000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7fc6ea286000 close(3) = 0 open("/usr/lib64/tls/libgcrypt.so.11", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libgcrypt.so.11", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\210\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=466208, ...}) = 0 mmap(NULL, 2562752, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6e9e06000 mprotect(0x7fc6e9e74000, 2097152, PROT_NONE) = 0 mmap(0x7fc6ea074000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6e000) = 0x7fc6ea074000 close(3) = 0 open("/usr/lib64/tls/libgpg-error.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libgpg-error.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\10\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=14152, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5e0000 mmap(NULL, 2109528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6e9c02000 mprotect(0x7fc6e9c05000, 2093056, PROT_NONE) = 0 mmap(0x7fc6e9e04000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fc6e9e04000 close(3) = 0 open("/usr/lib64/tls/libkrb5support.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libkrb5support.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\37\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=31384, ...}) = 0 mmap(NULL, 2126736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc6e99fa000 mprotect(0x7fc6e9a01000, 2093056, PROT_NONE) = 0 mmap(0x7fc6e9c00000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7fc6e9c00000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5df000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5de000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5dd000 arch_prctl(ARCH_SET_FS, 0x7fc6ec5dd750) = 0 mprotect(0x7fc6e9c00000, 4096, PROT_READ) = 0 mprotect(0x7fc6e9e04000, 4096, PROT_READ) = 0 mprotect(0x7fc6ea074000, 4096, PROT_READ) = 0 mprotect(0x7fc6ea286000, 4096, PROT_READ) = 0 mprotect(0x7fc6ea5d0000, 16384, PROT_READ) = 0 mprotect(0x7fc6ea7dd000, 4096, PROT_READ) = 0 mprotect(0x7fc6ea9e2000, 4096, PROT_READ) = 0 mprotect(0x7fc6eac79000, 24576, PROT_READ) = 0 mprotect(0x7fc6eae82000, 4096, PROT_READ) = 0 mprotect(0x7fc6eb096000, 4096, PROT_READ) = 0 mprotect(0x7fc6eb29c000, 4096, PROT_READ) = 0 mprotect(0x7fc6eb4c0000, 8192, PROT_READ) = 0 mprotect(0x7fc6eb751000, 12288, PROT_READ) = 0 mprotect(0x7fc6eb97e000, 4096, PROT_READ) = 0 mprotect(0x7fc6ebbc2000, 4096, PROT_READ) = 0 mprotect(0x7fc6ebdd7000, 4096, PROT_READ) = 0 mprotect(0x7fc6ebfd9000, 4096, PROT_READ) = 0 mprotect(0x7fc6ec1f0000, 4096, PROT_READ) = 0 mprotect(0x7fc6ec3fd000, 4096, PROT_READ) = 0 mprotect(0x631000, 4096, PROT_READ) = 0 mprotect(0x7fc6ec61b000, 4096, PROT_READ) = 0 munmap(0x7fc6ec5e6000, 207105) = 0 set_tid_address(0x7fc6ec5dd7e0) = 19842 set_robust_list(0x7fc6ec5dd7f0, 0x18) = 0 futex(0x7fffff9a556c, FUTEX_WAKE_PRIVATE, 1) = 0 rt_sigaction(SIGRTMIN, {0x7fc6ebfe0670, [], SA_RESTORER|SA_SIGINFO, 0x7fc6ebfe9910}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7fc6ebfe0700, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fc6ebfe9910}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x635000 brk(0x656000) = 0x656000 open("nweb.img", O_RDWR|O_CLOEXEC) = 3 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0 signalfd(4294967295, [USR2], 8) = 4 fcntl(4, F_GETFD) = 0 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 lseek(3, 0, SEEK_END) = 15321681920 lseek(3, 0, SEEK_SET) = 0 read(3, "QFI\373\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\5\0\0\0\0"..., 512) = 512 lseek(3, 4096, SEEK_SET) = 4096 read(3, "\200\0\0\0\0\1p\0\200\0\0\0\0! \0\200\0\0\0\0A0\0\200\0\0\0\0a@\0"..., 81920) = 81920 brk(0x67b000) = 0x67b000 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6ec5f8000 mmap(NULL, 1085652992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc6a8e9e000 lseek(3, 14235504640, SEEK_SET) = 14235504640 read(3, "\0\0\0\0\0\1`\0\0\0\0\0\0\200\260\0\0\0\0\0\1\1P\0\0\0\0\0\1\201\360\0"..., 1085648896) = 1085648896 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Segmentation fault Any way to loop mount the qcow2 image or something else? Thanks! Robert On 01/19/10 22:40, Robert Wimmer wrote: > Hi, > > I'm running Gentoo x86_64 with kernel 2.6.32 and Qemu/KVM 0.12.1.2. > Ran fine for about 10 days until today the qemu-system_x86_64 process > crashed with a segfault (: > > Jan 19 06:24:42 scotty kernel: [977458.908149] qemu-system-x86[8920]: segfault at 7f04daab8530 ip > 000000000047a614 sp 00007ffff65b1150 error 4 in qemu-system-x86_64[400000+213000] > > Now the image seems to be corrupt. I can't start the image anymore. > It takes a few second and I get the next segfault. Other images running > fine with the same parameters. The startup parameters are: > > /usr/bin/qemu-system-x86_64 --enable-kvm -m 512 -smp 2 -cpu host -daemonize -k de -vnc 127.0.0.1:1 - > monitor telnet:10.0.0.8:4444,server,nowait -localtime -pidfile /tmp/kvm-nweb.pid -drive > file=/opt/kvm/images/nweb.img,if=virtio,cache=none,boot=on -net > nic,vlan=0,model=virtio,macaddr=98:84:44:78:12:aa -net tap,vlan=0,ifname=tap.b.nweb,script=no > > When I try to convert the image to another format with > > qemu-img convert -f qcow2 -O raw source.img dest.img > > I also get segfault's: > > [1033227.955659] qemu-img[9990]: segfault at 7fd55eb48000 ip 000000000041a2d2 sp 00007fffc1a34fe0 > error 7 in qemu-img[400000+32000] > [1033236.379335] qemu-img[9991]: segfault at 7fd06332b000 ip 000000000041a2d2 sp 00007fff38eb5a90 > error 7 in qemu-img[400000+32000] > > Is there any chance to get (some) data in the image back? Backup is a few weeks old :-( > > Thanks! > Robert > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <229432dd1001220635t5ba74dah982d5e5862035a0@mail.gmail.com>]
* Re: Segfault [not found] ` <229432dd1001220635t5ba74dah982d5e5862035a0@mail.gmail.com> @ 2010-01-22 14:45 ` RW 0 siblings, 0 replies; 22+ messages in thread From: RW @ 2010-01-22 14:45 UTC (permalink / raw) To: Liang Guo; +Cc: KVM mailing list Thanks for the hint but unfortunately every qemu command quits with a segfault with this image: scotty images # qemu-nbd nweb.img Segmentation fault [192749.840652] qemu-nbd[16052]: segfault at 7f88b1382000 ip 0000000000419492 sp 00007fff1e94f710 error 7 in qemu-nbd[400000+31000] It's sad that a segfault of Qemu/KVM can corrupt a whole image while the host itself was running without any problems as the segfault happened. Seems that the data is lost. But thanks again anyway! Robert On 01/22/10 15:35, Liang Guo wrote: > > 2010/1/20 RW <kvm@tauceti.net <mailto:kvm@tauceti.net>> > > > > Is there any chance to get (some) data in the image back? Backup > is a few weeks old :-( > > > > > you may use kvm-nbd or qemu-nbd to present kvm image as a NBD device, so > that you can use nbd-client to access them. eg: > > kvm-nbd /vm/sid1.img > modprobe nbd > nbd-client localhost 1024 /dev/nbd0 > fdisk -l /dev/nbd0 > > -- > Liang Guo > http://bluestone.cublog.cn ^ permalink raw reply [flat|nested] 22+ messages in thread
* Segfault @ 2010-01-19 21:22 Robert Wimmer 0 siblings, 0 replies; 22+ messages in thread From: Robert Wimmer @ 2010-01-19 21:22 UTC (permalink / raw) To: kvm Hi, I'm running Gentoo x86_64 with kernel 2.6.32 and Qemu/KVM 0.12.1.2. Ran fine for about 10 days until today the qemu-system_x86_64 process crashed with a segfault (: Jan 19 06:24:42 scotty kernel: [977458.908149] qemu-system-x86[8920]: segfault at 7f04daab8530 ip 000000000047a614 sp 00007ffff65b1150 error 4 in qemu-system-x86_64[400000+213000] Now the image seems to be corrupt. I can't start the image anymore. It takes a few second and I get the next segfault. Other images running fine with the same parameters. The startup parameters are: /usr/bin/qemu-system-x86_64 --enable-kvm -m 512 -smp 2 -cpu host -daemonize -k de -vnc 127.0.0.1:1 - monitor telnet:10.0.0.8:4444,server,nowait -localtime -pidfile /tmp/kvm-nweb.pid -drive file=/opt/kvm/images/nweb.img,if=virtio,cache=none,boot=on -net nic,vlan=0,model=virtio,macaddr=98:84:44:78:12:aa -net tap,vlan=0,ifname=tap.b.nweb,script=no When I try to convert the image to another format with qemu-img convert -f qcow2 -O raw source.img dest.img I also get segfault's: [1033227.955659] qemu-img[9990]: segfault at 7fd55eb48000 ip 000000000041a2d2 sp 00007fffc1a34fe0 error 7 in qemu-img[400000+32000] [1033236.379335] qemu-img[9991]: segfault at 7fd06332b000 ip 000000000041a2d2 sp 00007fff38eb5a90 error 7 in qemu-img[400000+32000] Is there any chance to get (some) data in the image back? Backup is a few weeks old :-( Thanks! Robert ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: SEGFAULT
@ 2003-08-20 19:21 Sandro Dangui
0 siblings, 0 replies; 22+ messages in thread
From: Sandro Dangui @ 2003-08-20 19:21 UTC (permalink / raw)
To: John T. Williams, linux-c-programming
I can see two mistakes:
First, you have to initialize hostnamelength = sizeof(HOSTNAME);
Second, accept() doesn't alloc memory to return data in sockaddr_in*;
Then, you must define "active" variable like this: struct sockaddr_in
active;
And call: accept(skt, (struct sockaddr *) &active, &activeLen);
-----Original Message-----
From: John T. Williams [mailto:jtwilliams@vt.edu]
Sent: quarta-feira, 20 de agosto de 2003 15:56
To: linux-c-programming@vger.kernel.org
Subject: SEGFAULT
I can't figure out why this code sigfaults when it exits. gdb only tells
me
Program received signal SIGSEGV
0xda64a8c0 in ? ()
and shows the step as being the final "}" in main ().
as far as I can tell this means either one of the linux libraries is wrong
or my code is doing something funny with a buffer. I'll gladly e-mail a
dollar to anyone who can tell me what is wrong with this short bit of code.
Well, I mean what is wrong that causes the SIGSEGV.
_________________CODE______________________
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <netinet/in.h>
#include <unistd.h>
#include <netdb.h>
#define HOST_NAME_MAX 255
int main( ) {
int loop;
struct sockaddr_in *active;
struct sockaddr_in passive;
struct hostent *host;
struct protoent *proto;
int port, activeLen, newSkt, skt;
char HOSTNAME[HOST_NAME_MAX];
int hostnamelength;
int pid;
host = NULL;
proto = getprotobyname("tcp");
if( ( skt = socket(PF_INET, SOCK_STREAM, proto->p_proto ) ) == -1 ) {
printf("Cannot create socket\n");
exit(1);
}
if(gethostname(HOSTNAME, hostnamelength) ) {
printf("fuck\n");
exit(1);
}
host = gethostbyname(HOSTNAME);
passive.sin_family = host->h_addrtype;
passive.sin_port = htons( 4023 );
bcopy(host->h_addr, &passive.sin_addr, host->h_length);
if(bind(skt, (struct sockaddr *) &passive, sizeof(passive) ) ) {
printf("bind failed\n");
exit(1);
}
if( listen(skt, 10) ) {
printf("listen failed\n");
close(skt);
exit(1);
}
activeLen = sizeof(active);
for(loop=0;loop<2;loop++) {
newSkt = accept(skt, (struct sockaddr *) active, &activeLen);
if( (pid = fork() ) == 0 ) {
close(skt);
printf("connection accepted\n");
fflush(NULL);
close(newSkt);
_exit(0);
} else close(newSkt);
}
wait(NULL);
sleep(1);
close(skt);
return 0;
}
_______________________END CODE________________
-
To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 22+ messages in thread* Parsing multipart MIME
@ 2003-08-15 18:05 Darío Mariani
2003-08-20 18:56 ` SEGFAULT John T. Williams
0 siblings, 1 reply; 22+ messages in thread
From: Darío Mariani @ 2003-08-15 18:05 UTC (permalink / raw)
To: linux-c-programming
Hello:
I'm building a minimal MIME parser, mainly to separate the parts in a
multipart/form-data in a web POST. I was wondering if anyone made the
regular expression for interpreting it. I thought of this:
multip ::= start anychar* (delim anychar*)* end?
anychar ::= <any character including \0>
delim ::= <delimiter>
start ::= "--" delim "\r\n"
middle ::= "\r\n--" delim "\r\n"
end ::= "\r\n--" delim "--"
I have little experience with grammars so this expression may be
wrong. Any ideas? thanks,
Darío
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 22+ messages in thread* SEGFAULT 2003-08-15 18:05 Parsing multipart MIME Darío Mariani @ 2003-08-20 18:56 ` John T. Williams 2003-08-20 19:35 ` SEGFAULT Glynn Clements 0 siblings, 1 reply; 22+ messages in thread From: John T. Williams @ 2003-08-20 18:56 UTC (permalink / raw) To: linux-c-programming I can't figure out why this code sigfaults when it exits. gdb only tells me Program received signal SIGSEGV 0xda64a8c0 in ? () and shows the step as being the final "}" in main (). as far as I can tell this means either one of the linux libraries is wrong or my code is doing something funny with a buffer. I'll gladly e-mail a dollar to anyone who can tell me what is wrong with this short bit of code. Well, I mean what is wrong that causes the SIGSEGV. _________________CODE______________________ #include <sys/types.h> #include <sys/socket.h> #include <sys/wait.h> #include <netinet/in.h> #include <unistd.h> #include <netdb.h> #define HOST_NAME_MAX 255 int main( ) { int loop; struct sockaddr_in *active; struct sockaddr_in passive; struct hostent *host; struct protoent *proto; int port, activeLen, newSkt, skt; char HOSTNAME[HOST_NAME_MAX]; int hostnamelength; int pid; host = NULL; proto = getprotobyname("tcp"); if( ( skt = socket(PF_INET, SOCK_STREAM, proto->p_proto ) ) == -1 ) { printf("Cannot create socket\n"); exit(1); } if(gethostname(HOSTNAME, hostnamelength) ) { printf("fuck\n"); exit(1); } host = gethostbyname(HOSTNAME); passive.sin_family = host->h_addrtype; passive.sin_port = htons( 4023 ); bcopy(host->h_addr, &passive.sin_addr, host->h_length); if(bind(skt, (struct sockaddr *) &passive, sizeof(passive) ) ) { printf("bind failed\n"); exit(1); } if( listen(skt, 10) ) { printf("listen failed\n"); close(skt); exit(1); } activeLen = sizeof(active); for(loop=0;loop<2;loop++) { newSkt = accept(skt, (struct sockaddr *) active, &activeLen); if( (pid = fork() ) == 0 ) { close(skt); printf("connection accepted\n"); fflush(NULL); close(newSkt); _exit(0); } else close(newSkt); } wait(NULL); sleep(1); close(skt); return 0; } _______________________END CODE________________ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: SEGFAULT 2003-08-20 18:56 ` SEGFAULT John T. Williams @ 2003-08-20 19:35 ` Glynn Clements 0 siblings, 0 replies; 22+ messages in thread From: Glynn Clements @ 2003-08-20 19:35 UTC (permalink / raw) To: John T. Williams; +Cc: linux-c-programming John T. Williams wrote: > I can't figure out why this code sigfaults when it exits. > gdb only tells me > > Program received signal SIGSEGV > 0xda64a8c0 in ? () > > and shows the step as being the final "}" in main (). Sandro has already pointed out some likely causes of the segfault. However, the above GDB output suggests that you compiled the program either without debug info (without -g), or without a frame pointer (with -fomit-frame-pointer), or that you subsequently stripped the debug info (e.g. with the -s linker switch). If you want to be able to debug a program, use the -g switch for both compilation and linking, and don't use any optimisation switches. -- Glynn Clements <glynn.clements@virgin.net> ^ permalink raw reply [flat|nested] 22+ messages in thread
* SegFault
@ 2002-06-25 20:13 Dan Egli
[not found] ` <3D18E115.9B5981C1@microsoft.com>
0 siblings, 1 reply; 22+ messages in thread
From: Dan Egli @ 2002-06-25 20:13 UTC (permalink / raw)
To: linux-msdos
I thought everything was working grand, when all of a sudden, I noticed that
DosEMU was crashing when I ran a certain program. This program starts up,
looks fine for a while, then all of a sudden, DosEMU dies. The error is
listed below (I tried to extract it from the program header on the screen so
if something is missing, sorry)
ERROR: unexpected CPU exception 0x06 err=0x00000000 cr2=00000000 while in
vm86 (DOS)
Program=sigsegv.c, Line=190
EIP: 0000:0000000c ESP: 2890:0000072c VFLAGS(b): 00000 00000010 00010010
EAX: 00000006 EBX: 276b0007 ECX: 00000002 EDX: 0000200d VFLAGS(h): 00000212
ESI: 00000007 EDI: 0000075f EBP: 00000000 DS: 1c58 ES: 0000 FS: 0000 GS:
0000
FLAGS: AF IF RF VM VIF IOPL: 06)
STACK: 00 20 07 00 00 00 00 00 00 00 -> 00 00 00 00 00 00 00 00 00 00
B0\x0f : aa 03 c6 20 97 0d 20 00 00 f0 -> c6 20 97 0d 29 02 70 00 50 00
= 62097 0000:000c mov [bx+si],97
Anyone know how I could fix this?
^ permalink raw reply [flat|nested] 22+ messages in thread[parent not found: <3D18E115.9B5981C1@microsoft.com>]
* Re: SegFault [not found] ` <3D18E115.9B5981C1@microsoft.com> @ 2002-06-26 0:56 ` Dan Egli 2002-06-26 1:02 ` SegFault Dan Egli 0 siblings, 1 reply; 22+ messages in thread From: Dan Egli @ 2002-06-26 0:56 UTC (permalink / raw) To: bonz; +Cc: linux-msdos Sorry! I was rushed and I forgot some things! I'm CCing the list on this.. Distribution: RedHat 7.3 DosEMU Ver (as reported by RPM) 1.1.1-3 DOS ver: Caldera Dr-Dos 7.03 Program: FastEcho 1.46 (I'd not be surprised if no one has heard of it). EMS/XMS/DPMI define: 8192KB CPU defined: 80586 PCI: On Anything else that would be of value? I'll name it off if requested. ----- Original Message ----- From: "Bonz" <lemmings@microsoft.com> To: "Dan Egli" <dan@shortcircuit.dyndns.org> Sent: Tuesday, June 25, 2002 3:31 PM Subject: Re: SegFault > Dan Egli wrote: > > > > I thought everything was working grand, when all of a sudden, I noticed that > > DosEMU was crashing when I ran a certain program. This program starts up, > > looks fine for a while, then all of a sudden, DosEMU dies. The error is > > listed below (I tried to extract it from the program header on the screen so > > if something is missing, sorry) > > > > ERROR: unexpected CPU exception 0x06 err=0x00000000 cr2=00000000 while in > > vm86 (DOS) > > Program=sigsegv.c, Line=190 > > EIP: 0000:0000000c ESP: 2890:0000072c VFLAGS(b): 00000 00000010 00010010 > > EAX: 00000006 EBX: 276b0007 ECX: 00000002 EDX: 0000200d VFLAGS(h): 00000212 > > ESI: 00000007 EDI: 0000075f EBP: 00000000 DS: 1c58 ES: 0000 FS: 0000 GS: > > 0000 > > FLAGS: AF IF RF VM VIF IOPL: 06) > > STACK: 00 20 07 00 00 00 00 00 00 00 -> 00 00 00 00 00 00 00 00 00 00 > > B0\x0f : aa 03 c6 20 97 0d 20 00 00 f0 -> c6 20 97 0d 29 02 70 00 50 00 > > = 62097 0000:000c mov [bx+si],97 > > > > Anyone know how I could fix this? > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-msdos" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > That's not very helpful. > > If you are expecting a response from the list supply at the very least, > the distribution you are using, for instance debian woody > the version of dosemu you are running, for instance 1.0.2.1 > the actual operating system you are using, for instance DR Open-DOS > 7.02, > the program that caused the error, for instance master of magic 2.3 > > It is quite possible that different dos versions might work under dosemu > with the software you are trying to run. > By supplying this information people can try other versions of dos & > determine the exact cause of the problem & possibly even suggest a > solution like (freedos does not support blah-blah & will cause dosemu to > segfault, try opendos 6.3 or higher instead) > > When you report a problem with your car to a mechanic over the phone, do > you withhold the model & year of your car & expect him to provide you > with a quote to fix the problem? > > Other things that may help define the problem would be certain > configuration parameters like the amount of ems, etc you have > configured, especially if the program you are trying to use creates a > lot of memory pages. > I suggest you relook at the problem & then ask yourself If I was helping > me to fix this what would I need to know? > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: SegFault 2002-06-26 0:56 ` SegFault Dan Egli @ 2002-06-26 1:02 ` Dan Egli 0 siblings, 0 replies; 22+ messages in thread From: Dan Egli @ 2002-06-26 1:02 UTC (permalink / raw) Cc: linux-msdos One more thing that could be of value is the config.sys file, so it is pasted below: DEVICE=C:\DRDOS\SETVER.EXE SHELL=C:\COMMAND.COM C:\ /E:512 /P BREAK=ON BUFFERS=30 LASTDRIVE=Z HISTORY=ON,512,ON COUNTRY=1,,C:\DRDOS\COUNTRY.SYS DOS=HIGH,UMB FILES=100 ----- Original Message ----- From: "Dan Egli" <dan@shortcircuit.dyndns.org> To: <bonz@misty.apana.org.au> Cc: <linux-msdos@vger.kernel.org> Sent: Tuesday, June 25, 2002 6:56 PM Subject: Re: SegFault > Sorry! I was rushed and I forgot some things! > > I'm CCing the list on this.. > > Distribution: RedHat 7.3 > DosEMU Ver (as reported by RPM) 1.1.1-3 > DOS ver: Caldera Dr-Dos 7.03 > Program: FastEcho 1.46 (I'd not be surprised if no one has heard of it). > EMS/XMS/DPMI define: 8192KB > CPU defined: 80586 > PCI: On > > Anything else that would be of value? I'll name it off if requested. > ----- Original Message ----- > From: "Bonz" <lemmings@microsoft.com> > To: "Dan Egli" <dan@shortcircuit.dyndns.org> > Sent: Tuesday, June 25, 2002 3:31 PM > Subject: Re: SegFault > > > > Dan Egli wrote: > > > > > > I thought everything was working grand, when all of a sudden, I noticed > that > > > DosEMU was crashing when I ran a certain program. This program starts > up, > > > looks fine for a while, then all of a sudden, DosEMU dies. The error is > > > listed below (I tried to extract it from the program header on the > screen so > > > if something is missing, sorry) > > > > > > ERROR: unexpected CPU exception 0x06 err=0x00000000 cr2=00000000 while > in > > > vm86 (DOS) > > > Program=sigsegv.c, Line=190 > > > EIP: 0000:0000000c ESP: 2890:0000072c VFLAGS(b): 00000 00000010 > 00010010 > > > EAX: 00000006 EBX: 276b0007 ECX: 00000002 EDX: 0000200d VFLAGS(h): > 00000212 > > > ESI: 00000007 EDI: 0000075f EBP: 00000000 DS: 1c58 ES: 0000 FS: 0000 GS: > > > 0000 > > > FLAGS: AF IF RF VM VIF IOPL: 06) > > > STACK: 00 20 07 00 00 00 00 00 00 00 -> 00 00 00 00 00 00 00 00 00 00 > > > B0\x0f : aa 03 c6 20 97 0d 20 00 00 f0 -> c6 20 97 0d 29 02 70 00 50 00 > > > = 62097 0000:000c mov [bx+si],97 > > > > > > Anyone know how I could fix this? > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-msdos" > in > > > the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > That's not very helpful. > > > > If you are expecting a response from the list supply at the very least, > > the distribution you are using, for instance debian woody > > the version of dosemu you are running, for instance 1.0.2.1 > > the actual operating system you are using, for instance DR Open-DOS > > 7.02, > > the program that caused the error, for instance master of magic 2.3 > > > > It is quite possible that different dos versions might work under dosemu > > with the software you are trying to run. > > By supplying this information people can try other versions of dos & > > determine the exact cause of the problem & possibly even suggest a > > solution like (freedos does not support blah-blah & will cause dosemu to > > segfault, try opendos 6.3 or higher instead) > > > > When you report a problem with your car to a mechanic over the phone, do > > you withhold the model & year of your car & expect him to provide you > > with a quote to fix the problem? > > > > Other things that may help define the problem would be certain > > configuration parameters like the amount of ems, etc you have > > configured, especially if the program you are trying to use creates a > > lot of memory pages. > > I suggest you relook at the problem & then ask yourself If I was helping > > me to fix this what would I need to know? > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-msdos" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: segfault
@ 2001-09-05 21:53 Jim Paris
0 siblings, 0 replies; 22+ messages in thread
From: Jim Paris @ 2001-09-05 21:53 UTC (permalink / raw)
To: linux-mips
[ resending to list, since I accidently replied only to Maciej ]
> Since there appears to be no conclusion of the sysmips-on-MIPS-I problem
> in sight, I've just put all the related patches I use in a single place
> for easy retrieval. All of them were sent to this mailing list once but
> digging through archives is tiresome. Get them from
> 'ftp://ftp.ds2.pg.gda.pl/pub/macro/sysmips/'.
>
> There is a sys_sysmips() fix in the "sysmips-1" patch and two additional
> patches implementing a sys__test_and_set() syscall and its usage in glibc.
> Feel free to use them until an official solution is available.
I applied these patches and I still have the same problem.
I'm starting to think that maybe my kernel is just too broken to use
with my recent binutils/gcc/glibc mix. I was hoping that my efforts
to patch it up to 2.4.5 would have fixed that; I wish the linux-vr
tree was still being updated by people who actually knew what they
were doing (as I certainly don't).
-jim
^ permalink raw reply [flat|nested] 22+ messages in thread* segfault @ 2001-09-05 3:54 Jim Paris 2001-09-05 17:15 ` segfault Florian Lohoff 2001-09-13 18:59 ` segfault Jim Paris 0 siblings, 2 replies; 22+ messages in thread From: Jim Paris @ 2001-09-05 3:54 UTC (permalink / raw) To: linux-mips I'm trying to get Linux working on my handheld PC (the Sharp Tripad, very similar to the Vadem Clio), but I'm having userland problems. Some binaries compile and run fine, while others give a segfault right away. Compiling with slightly different versions of compilers, glibc, etc, seems to affect which binaries work and which don't, although I can't find a combination that seems to work with everything. Fortunately, one binary that does appear to work fine is 'sash', which lets me test this stuff. I uncommented some debugging stuff in the kernel, and the actual error is: do_page_fault( )#2: sending SIGSEGV to test-prog for illegal write access to 00000fd4 (epc == 004027b8, ra == 00402730) The strange part about this (and the reason why I suspect someone may be able to help me) is that the address 00000fd4 is always the same, implying that the binaries are all failing in the same way. Has anyone seen this or does anyone have any ideas why this may be happening? My original setup was a pre-3.0 CVS GCC and glibc-2.2.3 with the Linux-VR kernel (based on the MIPS tree as of 2.4.0-test9), but I've since brought the Linux-VR tree up to 2.4.5 and moved to gcc-3.0.1 and glibc-2.2.4 with binutils-2.11.90.0.31, and none of this really seems to help the problem much. -jim ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: segfault 2001-09-05 3:54 segfault Jim Paris @ 2001-09-05 17:15 ` Florian Lohoff 2001-09-05 18:05 ` segfault Maciej W. Rozycki 2001-09-05 21:51 ` segfault Jim Paris 2001-09-13 18:59 ` segfault Jim Paris 1 sibling, 2 replies; 22+ messages in thread From: Florian Lohoff @ 2001-09-05 17:15 UTC (permalink / raw) To: Jim Paris; +Cc: linux-mips On Tue, Sep 04, 2001 at 11:54:10PM -0400, Jim Paris wrote: > > do_page_fault( )#2: sending SIGSEGV to test-prog for illegal write > access to 00000fd4 (epc == 004027b8, ra == 00402730) > > The strange part about this (and the reason why I suspect someone may > be able to help me) is that the address 00000fd4 is always the same, > implying that the binaries are all failing in the same way. Has > anyone seen this or does anyone have any ideas why this may be > happening? Do you have a fix for the sysmips(MIPS_ATOMIC_SET) in there ? Or do you have the glibc compiled as -mips2 for usage of ll/sc ? This bug might be a register corruption due to wrong return path in the sysmips case. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: segfault 2001-09-05 17:15 ` segfault Florian Lohoff @ 2001-09-05 18:05 ` Maciej W. Rozycki 2001-09-05 21:51 ` segfault Jim Paris 1 sibling, 0 replies; 22+ messages in thread From: Maciej W. Rozycki @ 2001-09-05 18:05 UTC (permalink / raw) To: Florian Lohoff; +Cc: Jim Paris, linux-mips On Wed, 5 Sep 2001, Florian Lohoff wrote: > Do you have a fix for the sysmips(MIPS_ATOMIC_SET) in there ? Or do > you have the glibc compiled as -mips2 for usage of ll/sc ? > > This bug might be a register corruption due to wrong return path > in the sysmips case. Since there appears to be no conclusion of the sysmips-on-MIPS-I problem in sight, I've just put all the related patches I use in a single place for easy retrieval. All of them were sent to this mailing list once but digging through archives is tiresome. Get them from 'ftp://ftp.ds2.pg.gda.pl/pub/macro/sysmips/'. There is a sys_sysmips() fix in the "sysmips-1" patch and two additional patches implementing a sys__test_and_set() syscall and its usage in glibc. Feel free to use them until an official solution is available. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: segfault 2001-09-05 17:15 ` segfault Florian Lohoff 2001-09-05 18:05 ` segfault Maciej W. Rozycki @ 2001-09-05 21:51 ` Jim Paris 1 sibling, 0 replies; 22+ messages in thread From: Jim Paris @ 2001-09-05 21:51 UTC (permalink / raw) To: linux-mips > Do you have a fix for the sysmips(MIPS_ATOMIC_SET) in there ? Or do > you have the glibc compiled as -mips2 for usage of ll/sc ? Yes, I'm pretty sure that fix is in there. I'm confused by the whole mips1/mips2/mips3 thing -- should I be compiling everything with the same -mipsN, and if so, which one? I have a VR41xx processor. The binaries I'm attempting to run are reported by file(1) as being MIPS 1, while the kernel image is reported as being MIPS 3 (even though most of the kernel Makefiles specify -mips2..?) If I use -mips2 when compiling my userspace binaries, the output files are the same size but different, but file(1) still reports them as MIPS 1 and they still crash in the same way. -jim ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: segfault 2001-09-05 3:54 segfault Jim Paris 2001-09-05 17:15 ` segfault Florian Lohoff @ 2001-09-13 18:59 ` Jim Paris 1 sibling, 0 replies; 22+ messages in thread From: Jim Paris @ 2001-09-13 18:59 UTC (permalink / raw) To: linux-mips > I'm trying to get Linux working on my handheld PC (the Sharp Tripad, > very similar to the Vadem Clio), but I'm having userland problems. > Some binaries compile and run fine, while others give a segfault right > away. Aha! I think I've finally found the problem, thanks to a lightbulb that blinked on after reading Kjeld's mail about optimization problems. I compile everything with -O3 (it's in my environment) and that apparently resulted in broken binaries. I rebuilt binutils, gcc, glibc, and all of my test binaries with -O1.. and everything appears to work perfectly. (after wrestling with this for weeks on end, I feel pretty stupid that it turned out to be something so simple, but I'm also quite elated that it works) Next step: conquer the world! (or, at least, set up user-space stuff) -jim ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-01-02 10:11 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-06-26 1:56 SegFault Stas Sergeev
2002-06-26 3:11 ` SegFault Dan Egli
2002-06-26 3:14 ` SegFault Dan Egli
-- strict thread matches above, loose matches on Subject: below --
2017-12-29 9:04 Segfault Andrew Tsykhonya
2017-12-31 8:59 ` Segfault Eric Sunshine
2018-01-02 10:11 ` Segfault Andrew Tsykhonya
2010-01-19 21:40 Segfault Robert Wimmer
2010-01-20 10:34 ` Segfault RW
[not found] ` <229432dd1001220635t5ba74dah982d5e5862035a0@mail.gmail.com>
2010-01-22 14:45 ` Segfault RW
2010-01-19 21:22 Segfault Robert Wimmer
2003-08-20 19:21 SEGFAULT Sandro Dangui
2003-08-15 18:05 Parsing multipart MIME Darío Mariani
2003-08-20 18:56 ` SEGFAULT John T. Williams
2003-08-20 19:35 ` SEGFAULT Glynn Clements
2002-06-25 20:13 SegFault Dan Egli
[not found] ` <3D18E115.9B5981C1@microsoft.com>
2002-06-26 0:56 ` SegFault Dan Egli
2002-06-26 1:02 ` SegFault Dan Egli
2001-09-05 21:53 segfault Jim Paris
2001-09-05 3:54 segfault Jim Paris
2001-09-05 17:15 ` segfault Florian Lohoff
2001-09-05 18:05 ` segfault Maciej W. Rozycki
2001-09-05 21:51 ` segfault Jim Paris
2001-09-13 18:59 ` segfault Jim Paris
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.