All of lore.kernel.org
 help / color / mirror / Atom feed
* 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

* 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

* 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

* 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
       [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

* 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

* 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

* 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 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
  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
  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

* 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 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  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
       [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

* 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

* 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

* 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

* 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 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  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

* 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

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 --
2003-08-20 19:21 SEGFAULT Sandro Dangui
  -- 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-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-26  1:56 SegFault Stas Sergeev
2002-06-26  3:11 ` SegFault Dan Egli
2002-06-26  3:14 ` SegFault Dan Egli
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.