Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #15450 > unrolled thread

string close causes SIGSEGV

Back to article view | Back to comp.lang.c++

Contents

  string close causes SIGSEGV Lacek <mateusz.lacki@gmail.com> - 2012-04-18 03:12 -0700
    Re: string close causes SIGSEGV jt@toerring.de (Jens Thoms Toerring) - 2012-04-18 10:32 +0000
    Re: string close causes SIGSEGV Juha Nieminen <nospam@thanks.invalid> - 2012-04-18 11:09 +0000
    Re: string close causes SIGSEGV drew@furrfu.invalid (Drew Lawson) - 2012-04-18 17:50 +0000
      Re: string close causes SIGSEGV gof@somewhere.invalid (Gof) - 2012-04-19 08:05 +0000

#15450 — string close causes SIGSEGV

Dear All,
I have run into  a problem when closing a string. In particular I open
a ofstream, I write about 40 lines of numbers. After that I close the
stream:

file.close();

but that line seems to cause a SIGSEGV. THis is confirmed by a
debugger:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff73151a8 in _int_free (av=0x7ffff76361c0, p=0x636b00) at
malloc.c:4973
4973	malloc.c: Nie ma takiego pliku ani katalogu.
	in malloc.c
(gdb) bt
#0  0x00007ffff73151a8 in _int_free (av=0x7ffff76361c0, p=0x636b00) at
malloc.c:4973
#1  0x00007ffff73189cc in __GI___libc_free (mem=<optimized out>) at
malloc.c:3738
#2  0x00007ffff7304365 in _IO_new_fclose (fp=0x636d70) at iofclose.c:
88
#3  0x00007ffff7b4abc0 in std::__basic_file<char>::close() () from /
usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff7b4e411 in std::basic_filebuf<char,
std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/
libstdc++.so.6
#5  0x00007ffff7b4ff9d in std::basic_ofstream<char,
std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/
libstdc++.so.6
#6  0x000000000040478e in main ()

Compiler is:
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

is it something obvious? This is a very last instruction in the code.
I suppose that bugs totaly unrelated to io cause that instruction it
to fail (overwriting stream's memory or sth like that ) and my code
requires a general debugging (its quite fresh), but perhaps I am
wrong.

Regards,
Mateusz Łącki

[toc] | [next] | [standalone]

#15451

Lacek <mateusz.lacki@gmail.com> wrote:
> I have run into  a problem when closing a string. In particular I open
> a ofstream, I write about 40 lines of numbers. After that I close the
> stream:

> file.close();

> but that line seems to cause a SIGSEGV. THis is confirmed by a
> debugger:

> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff73151a8 in _int_free (av=0x7ffff76361c0, p=0x636b00) at
> malloc.c:4973
> 4973    malloc.c: Nie ma takiego pliku ani katalogu.
>         in malloc.c
> (gdb) bt
> #0  0x00007ffff73151a8 in _int_free (av=0x7ffff76361c0, p=0x636b00) at
> malloc.c:4973
> #1  0x00007ffff73189cc in __GI___libc_free (mem=<optimized out>) at
> malloc.c:3738
> #2  0x00007ffff7304365 in _IO_new_fclose (fp=0x636d70) at iofclose.c:
> 88
> #3  0x00007ffff7b4abc0 in std::__basic_file<char>::close() () from /
> usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #4  0x00007ffff7b4e411 in std::basic_filebuf<char,
> std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/
> libstdc++.so.6
> #5  0x00007ffff7b4ff9d in std::basic_ofstream<char,
> std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/
> libstdc++.so.6
> #6  0x000000000040478e in main ()

> Compiler is:
> gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

> is it something obvious? This is a very last instruction in the code.
> I suppose that bugs totaly unrelated to io cause that instruction it
> to fail (overwriting stream's memory or sth like that ) and my code
> requires a general debugging (its quite fresh), but perhaps I am
> wrong.

You're correct - this is extremely unlikely to be a result
of some bug in close() etc. It looks like a typical memory
corruption problem which can be anywhere within your code
executed before the close() call.

If inspection of your code doesn't result in you finding the
bug you could try the 'valgrind' program to help you to find
the reasons.
                              Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#15452

Lacek <mateusz.lacki@gmail.com> wrote:
> Compiler is:
> gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

  Compile using the option -D_GLIBCXX_DEBUG and then try again.

  If that doesn't help catching the actual problem, run the program
using valgrind.

[toc] | [prev] | [next] | [standalone]

#15457

In article <ad9d6b28-de64-413b-9de8-5a0ab04486f4@a5g2000vbl.googlegroups.com>
	Lacek <mateusz.lacki@gmail.com> writes:
>Dear All,
>I have run into  a problem when closing a string. In particular I open
>a ofstream, I write about 40 lines of numbers. After that I close the
>stream:
>
>file.close();
>
>but that line seems to cause a SIGSEGV. THis is confirmed by a
>debugger:

No it isn't.

The debugger confirms that is *when* it happened, not that it was
the cause.  Almost certainly the reason that line resulted in a
SIGSEGV is that the object "file" was trashed before that line was
executed.

In addition to the tools others have pointed to, stare at the code
and look at:
  -- any pointer usage, including where you pass &variable into a
     library routine (especially any C-string routines)
  -- any array handling, check sizes and how you limit the subscript
     ranges, remember they differ by 1
  -- be suspicious of the variables declared right arount "file".
     The one just before is the prime suspect, but not the only one.

You are almost certainly writing over memory by exceeding the size
of something that you declared.

Be Aware: adding debugging code may change or hide the symptoms of
your bug.  That doesn't mean that it fixed things.

If all else fails, post the actual code (or the smallest workable
subset) that crashes.

-- 
 Drew Lawson

 ". . . And I never give a reason"
    -- God, as channeled by Seven Nations

[toc] | [prev] | [next] | [standalone]

#15468

Drew Lawson <drew@furrfu.invalid> wrote:

> Almost certainly the reason that line resulted in a SIGSEGV is that 
> the object "file" was trashed before that line was executed.

The same came to my mind - I've experienced it.

Consider the code:

std::string *a = new std::string("test");
std::string &b = *a;
delete a;
b.clear();

-- 
Gof

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web