Segmentation fault while COPY in 7.3

Segmentation fault while COPY in 7.3

Post by Nicolai Tufa » Mon, 02 Dec 2002 12:51:49



Help!
Backend crashes on any COPY command I issue:
PostgreSQL is 7.3 release, is compiled from sources.
The message I get is:

apb=# COPY maras2.mrk_yyn (bsvr_no, yyn_tur, yyn_no, yyn_syf, yyn_trh) TO
stdout;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#

The output of strace on backend is following:

# strace -p 18883
recv(7, "QCOPY maras2.mrk_yyn (bsvr_no, y"..., 8192, 0) = 77
gettimeofday({1038713111, 629131}, NULL) = 0
_llseek(11, 0, [0], SEEK_SET)           = 0
read(11, "\0\0\0\0\20\0\0\0\1\0\0\0\24\0\360\37\360\37\1 b1\5\0\1"..., 8192)
= 8192
read(11, "\0\0\0\0x#\375\"\20\0\0\0008\0h\35\360\37\1 \370\235\220"...,
8192) = 8192
_llseek(12, 0, [0], SEEK_SET)           = 0

= 8192
_llseek(21, 40960, [40960], SEEK_SET)   = 0
read(21, "\0\0\0\0\4\251\3#\20\0\0\0004\4p\17\360\37\1 \340\237 "..., 8192)
= 8192
_llseek(22, 106496, [106496], SEEK_SET) = 0
read(22, "\0\0\0\0(\326\377\"\20\0\0\0\10\1\200\1\0 \1 \200\237\0"..., 8192)
= 8192
read(17, "\0\0\0\0\20\0\0\0\1\0\0\0\360\0\20\1\0 \1 p\237 \1\340"..., 8192)
= 8192
open("/data/pgsql/base/2015749/2015757", O_RDWR|O_LARGEFILE) = 39
_llseek(39, 0, [20037632], SEEK_END)    = 0
_llseek(39, 0, [0], SEEK_SET)           = 0
read(39, "\0\0\0\0\270\7\4#\20\0\0\0\300\1\350\1\0 \1 \270\237\216"...,
8192) = 8192
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
#

I have recompiled postgres with debug information enabled, run gdb, attached
to backend process
and caught SIGSEGV as following:

(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x081697bf in pfree (pointer=0x828a7b0) at mcxt.c:480
480             (*header->context->methods->free_p) (header->context,
pointer);
(gdb)

The output of bt is:

(gdb) bt
#0  0x081697bf in pfree (pointer=0x828a7b0) at mcxt.c:480
#1  0x080b37be in CopyTo (rel=0x402be088, attnumlist=0x828a3f8, binary=0
'\0', oids=0 '\0',
    fp=0x0, delim=0x81c2a57 "\t", null_print=0x81b2c22 "\\N") at copy.c:671
#2  0x080b32f6 in DoCopy (stmt=0x827b398) at copy.c:491
#3  0x08118a6a in pg_exec_query_string (query_string=0x827af48, dest=Remote,
    parse_context=0x8245378) at postgres.c:789
#4  0x08119b89 in PostgresMain (argc=4, argv=0xbfffd2a0, username=0x8240a81
"postgres")
    at postgres.c:2016
#5  0x08101d7c in DoBackend (port=0x8240950) at postmaster.c:2293
#6  0x081016c2 in BackendStartup (port=0x8240950) at postmaster.c:1915
#7  0x08100875 in ServerLoop () at postmaster.c:1000
#8  0x08100326 in PostmasterMain (argc=1, argv=0x82270c0) at
postmaster.c:779
#9  0x080debab in main (argc=1, argv=0xbfffdc34) at main.c:210
#10 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)

Thanks in advance,
Nic

---------------------------(end of broadcast)---------------------------

 
 
 

Segmentation fault while COPY in 7.3

Post by Nicolai Tuf » Mon, 02 Dec 2002 13:25:26


While waiting for help I decided to fix my problem by
brute-forcing it. I commented out offending call to pfree()
in src/backend/commands/copy.c at line 671. I may introduced
a memory leak, but it works fine for me now.

Best regards,
Nic.

*** ./src/backend/commands/copy.c.orig  Sun Dec  1 06:02:34 2002
--- ./src/backend/commands/copy.c       Sun Dec  1 06:02:48 2002
***************
*** 668,674 ****
                                                                  ObjectIdGetDatum(elements[attnum - 1]),
                                                        Int32GetDatum(attr[attnum - 1]->atttypmod)));
                                        CopyAttributeOut(fp, string, delim);
!                                       pfree(string);
                                }
                                else
                                {
--- 668,674 ----
                                                                  ObjectIdGetDatum(elements[attnum - 1]),
                                                        Int32GetDatum(attr[attnum - 1]->atttypmod)));
                                        CopyAttributeOut(fp, string, delim);
!                                       /*pfree(string);*/
                                }
                                else
                                {

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command


 
 
 

Segmentation fault while COPY in 7.3

Post by Tom La » Mon, 02 Dec 2002 13:57:31



> (gdb) bt
> #0  0x081697bf in pfree (pointer=0x828a7b0) at mcxt.c:480
> #1  0x080b37be in CopyTo (rel=0x402be088, attnumlist=0x828a3f8, binary=0
> '\0', oids=0 '\0',
>     fp=0x0, delim=0x81c2a57 "\t", null_print=0x81b2c22 "\\N") at copy.c:671
> #2  0x080b32f6 in DoCopy (stmt=0x827b398) at copy.c:491

Hm.  Offhand it would seem that somebody's output function is returning
a non-palloc'd string.  What are the datatypes in that table, exactly?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

 
 
 

Segmentation fault while COPY in 7.3

Post by Bruce Momji » Wed, 04 Dec 2002 14:03:18


Yes, we found a double pfree in 7.3.  There will be a fix in 7.3.1.

---------------------------------------------------------------------------


> Something is funny about this pfree()....here is a similar crash on a 7.2.3

> (gdb)                            
> #0  0x00420874 in heap_freetuple ()
> #1  0x004a8390 in acquire_sample_rows ()
> #2  0x004a75c8 in analyze_rel ()
> #3  0x0049f690 in vacuum ()
> #4  0x005585d8 in ProcessUtility ()
> #5  0x00553c78 in pg_exec_query_string ()
> #6  0x00555850 in PostgresMain ()
> #7  0x00524660 in DoBackend ()
> #8  0x00523d08 in BackendStartup ()
> #9  0x00521c18 in ServerLoop ()
> #10 0x005211c8 in PostmasterMain ()
> #11 0x004df3d8 in main ()
> #12 0x2ae34928 in __libc_start_main () from /lib/libc.so.6
> (gdb)


> >Help!
> >Backend crashes on any COPY command I issue:
> >PostgreSQL is 7.3 release, is compiled from sources.
> >The message I get is:

> >apb=# COPY maras2.mrk_yyn (bsvr_no, yyn_tur, yyn_no, yyn_syf, yyn_trh) TO
> >stdout;
> >server closed the connection unexpectedly
> >        This probably means the server terminated abnormally
> >        before or while processing the request.
> >The connection to the server was lost. Attempting reset: Failed.
> >!#

> >The output of strace on backend is following:

> ># strace -p 18883
> >recv(7, "QCOPY maras2.mrk_yyn (bsvr_no, y"..., 8192, 0) = 77
> >gettimeofday({1038713111, 629131}, NULL) = 0
> >_llseek(11, 0, [0], SEEK_SET)           = 0
> >read(11, "\0\0\0\0\20\0\0\0\1\0\0\0\24\0\360\37\360\37\1 b1\5\0\1"..., 8192)
> >= 8192
> >read(11, "\0\0\0\0x#\375\"\20\0\0\0008\0h\35\360\37\1 \370\235\220"...,
> >8192) = 8192
> >_llseek(12, 0, [0], SEEK_SET)           = 0

> >= 8192
> >_llseek(21, 40960, [40960], SEEK_SET)   = 0
> >read(21, "\0\0\0\0\4\251\3#\20\0\0\0004\4p\17\360\37\1 \340\237 "..., 8192)
> >= 8192
> >_llseek(22, 106496, [106496], SEEK_SET) = 0
> >read(22, "\0\0\0\0(\326\377\"\20\0\0\0\10\1\200\1\0 \1 \200\237\0"..., 8192)
> >= 8192
> >read(17, "\0\0\0\0\20\0\0\0\1\0\0\0\360\0\20\1\0 \1 p\237 \1\340"..., 8192)
> >= 8192
> >open("/data/pgsql/base/2015749/2015757", O_RDWR|O_LARGEFILE) = 39
> >_llseek(39, 0, [20037632], SEEK_END)    = 0
> >_llseek(39, 0, [0], SEEK_SET)           = 0
> >read(39, "\0\0\0\0\270\7\4#\20\0\0\0\300\1\350\1\0 \1 \270\237\216"...,
> >8192) = 8192
> >--- SIGSEGV (Segmentation fault) ---
> >+++ killed by SIGSEGV +++
> >#

> >I have recompiled postgres with debug information enabled, run gdb, attached
> >to backend process
> >and caught SIGSEGV as following:

> >(gdb) continue
> >Continuing.

> >Program received signal SIGSEGV, Segmentation fault.
> >0x081697bf in pfree (pointer=0x828a7b0) at mcxt.c:480
> >480             (*header->context->methods->free_p) (header->context,
> >pointer);
> >(gdb)

> >The output of bt is:

> >(gdb) bt
> >#0  0x081697bf in pfree (pointer=0x828a7b0) at mcxt.c:480
> >#1  0x080b37be in CopyTo (rel=0x402be088, attnumlist=0x828a3f8, binary=0
> >'\0', oids=0 '\0',
> >    fp=0x0, delim=0x81c2a57 "\t", null_print=0x81b2c22 "\\N") at copy.c:671
> >#2  0x080b32f6 in DoCopy (stmt=0x827b398) at copy.c:491
> >#3  0x08118a6a in pg_exec_query_string (query_string=0x827af48, dest=Remote,
> >    parse_context=0x8245378) at postgres.c:789
> >#4  0x08119b89 in PostgresMain (argc=4, argv=0xbfffd2a0, username=0x8240a81
> >"postgres")
> >    at postgres.c:2016
> >#5  0x08101d7c in DoBackend (port=0x8240950) at postmaster.c:2293
> >#6  0x081016c2 in BackendStartup (port=0x8240950) at postmaster.c:1915
> >#7  0x08100875 in ServerLoop () at postmaster.c:1000
> >#8  0x08100326 in PostmasterMain (argc=1, argv=0x82270c0) at
> >postmaster.c:779
> >#9  0x080debab in main (argc=1, argv=0xbfffdc34) at main.c:210
> >#10 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
> >(gdb)

> >Thanks in advance,
> >Nic

> >---------------------------(end of broadcast)---------------------------

> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?

> http://www.postgresql.org/users-lounge/docs/faq.html

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

 
 
 

Segmentation fault while COPY in 7.3

Post by Tom La » Wed, 04 Dec 2002 15:53:14



> Yes, we found a double pfree in 7.3.  There will be a fix in 7.3.1.

The double pfree was in COPY, though.  This looks to be a different
issue.

Quote:>> (gdb)                            
>> #0  0x00420874 in heap_freetuple ()
>> #1  0x004a8390 in acquire_sample_rows ()
>> #2  0x004a75c8 in analyze_rel ()
>> #3  0x0049f690 in vacuum ()
>> #4  0x005585d8 in ProcessUtility ()
>> #5  0x00553c78 in pg_exec_query_string ()
>> #6  0x00555850 in PostgresMain ()

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

 
 
 

Segmentation fault while COPY in 7.3

Post by Bruce Momji » Thu, 05 Dec 2002 01:06:29


Ewe, yea.

---------------------------------------------------------------------------



> > Yes, we found a double pfree in 7.3.  There will be a fix in 7.3.1.

> The double pfree was in COPY, though.  This looks to be a different
> issue.

> >> (gdb)                            
> >> #0  0x00420874 in heap_freetuple ()
> >> #1  0x004a8390 in acquire_sample_rows ()
> >> #2  0x004a75c8 in analyze_rel ()
> >> #3  0x0049f690 in vacuum ()
> >> #4  0x005585d8 in ProcessUtility ()
> >> #5  0x00553c78 in pg_exec_query_string ()
> >> #6  0x00555850 in PostgresMain ()

>                    regards, tom lane

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

 
 
 

Segmentation fault while COPY in 7.3

Post by Medi Montase » Thu, 05 Dec 2002 04:45:39


Can I have a patch and would it work against 7.2.3.....

Thanks


>Yes, we found a double pfree in 7.3.  There will be a fix in 7.3.1.

>---------------------------------------------------------------------------


>>Something is funny about this pfree()....here is a similar crash on a 7.2.3

>>(gdb)                            
>>#0  0x00420874 in heap_freetuple ()
>>#1  0x004a8390 in acquire_sample_rows ()
>>#2  0x004a75c8 in analyze_rel ()
>>#3  0x0049f690 in vacuum ()
>>#4  0x005585d8 in ProcessUtility ()
>>#5  0x00553c78 in pg_exec_query_string ()
>>#6  0x00555850 in PostgresMain ()
>>#7  0x00524660 in DoBackend ()
>>#8  0x00523d08 in BackendStartup ()
>>#9  0x00521c18 in ServerLoop ()
>>#10 0x005211c8 in PostmasterMain ()
>>#11 0x004df3d8 in main ()
>>#12 0x2ae34928 in __libc_start_main () from /lib/libc.so.6
>>(gdb)


>>>Help!
>>>Backend crashes on any COPY command I issue:
>>>PostgreSQL is 7.3 release, is compiled from sources.
>>>The message I get is:

>>>apb=# COPY maras2.mrk_yyn (bsvr_no, yyn_tur, yyn_no, yyn_syf, yyn_trh) TO
>>>stdout;
>>>server closed the connection unexpectedly
>>>       This probably means the server terminated abnormally
>>>       before or while processing the request.
>>>The connection to the server was lost. Attempting reset: Failed.
>>>!#

>>>The output of strace on backend is following:

>>># strace -p 18883
>>>recv(7, "QCOPY maras2.mrk_yyn (bsvr_no, y"..., 8192, 0) = 77
>>>gettimeofday({1038713111, 629131}, NULL) = 0
>>>_llseek(11, 0, [0], SEEK_SET)           = 0
>>>read(11, "\0\0\0\0\20\0\0\0\1\0\0\0\24\0\360\37\360\37\1 b1\5\0\1"..., 8192)
>>>= 8192
>>>read(11, "\0\0\0\0x#\375\"\20\0\0\0008\0h\35\360\37\1 \370\235\220"...,
>>>8192) = 8192
>>>_llseek(12, 0, [0], SEEK_SET)           = 0

>>>= 8192
>>>_llseek(21, 40960, [40960], SEEK_SET)   = 0
>>>read(21, "\0\0\0\0\4\251\3#\20\0\0\0004\4p\17\360\37\1 \340\237 "..., 8192)
>>>= 8192
>>>_llseek(22, 106496, [106496], SEEK_SET) = 0
>>>read(22, "\0\0\0\0(\326\377\"\20\0\0\0\10\1\200\1\0 \1 \200\237\0"..., 8192)
>>>= 8192
>>>read(17, "\0\0\0\0\20\0\0\0\1\0\0\0\360\0\20\1\0 \1 p\237 \1\340"..., 8192)
>>>= 8192
>>>open("/data/pgsql/base/2015749/2015757", O_RDWR|O_LARGEFILE) = 39
>>>_llseek(39, 0, [20037632], SEEK_END)    = 0
>>>_llseek(39, 0, [0], SEEK_SET)           = 0
>>>read(39, "\0\0\0\0\270\7\4#\20\0\0\0\300\1\350\1\0 \1 \270\237\216"...,
>>>8192) = 8192
>>>--- SIGSEGV (Segmentation fault) ---
>>>+++ killed by SIGSEGV +++
>>>#

>>>I have recompiled postgres with debug information enabled, run gdb, attached
>>>to backend process
>>>and caught SIGSEGV as following:

>>>(gdb) continue
>>>Continuing.

>>>Program received signal SIGSEGV, Segmentation fault.
>>>0x081697bf in pfree (pointer=0x828a7b0) at mcxt.c:480
>>>480             (*header->context->methods->free_p) (header->context,
>>>pointer);
>>>(gdb)

>>>The output of bt is:

>>>(gdb) bt
>>>#0  0x081697bf in pfree (pointer=0x828a7b0) at mcxt.c:480
>>>#1  0x080b37be in CopyTo (rel=0x402be088, attnumlist=0x828a3f8, binary=0
>>>'\0', oids=0 '\0',
>>>   fp=0x0, delim=0x81c2a57 "\t", null_print=0x81b2c22 "\\N") at copy.c:671
>>>#2  0x080b32f6 in DoCopy (stmt=0x827b398) at copy.c:491
>>>#3  0x08118a6a in pg_exec_query_string (query_string=0x827af48, dest=Remote,
>>>   parse_context=0x8245378) at postgres.c:789
>>>#4  0x08119b89 in PostgresMain (argc=4, argv=0xbfffd2a0, username=0x8240a81
>>>"postgres")
>>>   at postgres.c:2016
>>>#5  0x08101d7c in DoBackend (port=0x8240950) at postmaster.c:2293
>>>#6  0x081016c2 in BackendStartup (port=0x8240950) at postmaster.c:1915
>>>#7  0x08100875 in ServerLoop () at postmaster.c:1000
>>>#8  0x08100326 in PostmasterMain (argc=1, argv=0x82270c0) at
>>>postmaster.c:779
>>>#9  0x080debab in main (argc=1, argv=0xbfffdc34) at main.c:210
>>>#10 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
>>>(gdb)

>>>Thanks in advance,
>>>Nic

>>>---------------------------(end of broadcast)---------------------------

>>---------------------------(end of broadcast)---------------------------
>>TIP 5: Have you checked our extensive FAQ?

>>http://www.postgresql.org/users-lounge/docs/faq.html

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

 
 
 

Segmentation fault while COPY in 7.3

Post by Medi Montase » Thu, 05 Dec 2002 04:52:55


FYI, I'm experiencing this with Async Queries (Async Purge and Aysnc
Vacuum).



>>Yes, we found a double pfree in 7.3.  There will be a fix in 7.3.1.

>The double pfree was in COPY, though.  This looks to be a different
>issue.

>>>(gdb)                            
>>>#0  0x00420874 in heap_freetuple ()
>>>#1  0x004a8390 in acquire_sample_rows ()
>>>#2  0x004a75c8 in analyze_rel ()
>>>#3  0x0049f690 in vacuum ()
>>>#4  0x005585d8 in ProcessUtility ()
>>>#5  0x00553c78 in pg_exec_query_string ()
>>>#6  0x00555850 in PostgresMain ()

>                    regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

 
 
 

Segmentation fault while COPY in 7.3

Post by Bruce Momji » Thu, 05 Dec 2002 05:07:17


I was wrong.  We found a COPY bug in 7.3 that will be fixed in 7.3.1.
Would you compile with symbols, -g, and send a new backtrace?

---------------------------------------------------------------------------


> FYI, I'm experiencing this with Async Queries (Async Purge and Aysnc
> Vacuum).



> >>Yes, we found a double pfree in 7.3.  There will be a fix in 7.3.1.

> >The double pfree was in COPY, though.  This looks to be a different
> >issue.

> >>>(gdb)                            
> >>>#0  0x00420874 in heap_freetuple ()
> >>>#1  0x004a8390 in acquire_sample_rows ()
> >>>#2  0x004a75c8 in analyze_rel ()
> >>>#3  0x0049f690 in vacuum ()
> >>>#4  0x005585d8 in ProcessUtility ()
> >>>#5  0x00553c78 in pg_exec_query_string ()
> >>>#6  0x00555850 in PostgresMain ()

> >                       regards, tom lane

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

 
 
 

1. Segmentation Fault with db2 library in Red Hat Linux 7.3 with UDB 7.1 Enterprise

I have a program that when compiled with g++ and the db2
library (e.g. -ldb2) that segmentation faults. Yet when I remove the
-ldb2 from the compliation it works without errors.

Anyone know about any issues with the library that might causes this,
or what we are doing wrong and how to fix/work around the problem.

I am using RedHat 7.3 and gcc 2.96.

Sample is here:

#include <sqlcli.h>

static bool TestIntException();
static bool TestDb2Call();

static struct TestDesc
{
  char *name;
  bool exec;
  bool (*func)(void);
{
  { "TestIntException", true, TestIntException },
  { "TestDb2Call", true, TestDb2Call },

#define NELEMS(array)           ( sizeof(array) / sizeof((array)[0]) )

int
main(void)
{
  for (int i = 0; i < NELEMS(tests); i++)
  {
    if (tests[i].exec != true)
      continue;

    bool rc = tests[i].func();
    printf("%s: %s\n", tests[i].name, rc ? "ok" : "FAILED");
  }

  return (0);

static bool
TestIntException()
{
  try
  {
    int n = 0;
    throw n;
  }
  catch (int e)
  {
    return (true);
  }

  return (false);

static bool
TestDb2Call()
{
  HENV env;
  SQLAllocEnv(&env);

  return (true);

gdb backtrace:

#0  0x00000000 in ?? ()
#1  0x40978348 in __user_type_info::dyncast (this=0x40986df0, boff=0,


/usr/lib/libstdc++-libc6.2-2.so.3
#2  0x4097a4e3 in __dynamic_cast_2 (from=0x4097aac0
<__builtin_type_info type_info function>,
    to=0x4097a980 <__pointer_type_info type_info function>, boff=0,
address=0x40986aa0,
    sub=0x40a08aac <type_info type_info function>, subptr=0x40986aa0)
from /usr/lib/libstdc++-libc6.2-2.so.3
#3  0x4097a2a3 in __is_pointer (p=0x40986aa0) from
/usr/lib/libstdc++-libc6.2-2.so.3
#4  0x40979796 in __cp_pop_exception (p=0x8049c88) from
/usr/lib/libstdc++-libc6.2-2.so.3
#5  0x080488ff in TestIntException () at except.cpp:45
#6  0x08048840 in main () at except.cpp:28
#7  0x42017499 in __libc_start_main () from /lib/i686/libc.so.6

Thanks in advance,
-Denis Serebro

2. Cannot determine if a logical expression is null

3. Segmentation fault in 7.3 while vacuuming

4. JDBC (java -MS Access)

5. Oracle 7.3 Problem - Segmentation fault

6. Turning off ODBC tracing from VB

7. Segmentation fault in 7.3

8. SELECT statement

9. installer Segmentation fault Oracle9i / SuSE 7.3

10. Installation on Solaris 2.5.1 -- Segmentation Fault

11. segmentation fault

12. segmentation fault with orainst

13. segmentation fault