istream segfault 
July 22nd, 2005, 05:46 PM
| | | |
Under what circumstances would closing a istream object (such as
'in.close()') SEGFAULT? | 
July 22nd, 2005, 05:46 PM
| | | | re: istream segfault
On Thu, 22 Jul 2004 15:04:23 -0400 (EDT), Jim Strathmeyer
<nospam.invalid@andrew.cmu.edu> wrote:
[color=blue]
>
> Under what circumstances would closing a istream object (such as
> 'in.close()') SEGFAULT?[/color]
When you have a bug in your program. What else?
All the usual suspects, writing past he end of an array, writing through a
garbage pointer, freeing the same memory twice, etc. etc. All these bugs
can cause anything to happen.
Bugs rarely have any logic. You can rarely say 'well the symptom is this,
therefore the bug must be that', at least that sort of intuition only
comes with much experience.
john | 
July 22nd, 2005, 05:46 PM
| | | | re: istream segfault
On Thu, 22 Jul 2004, John Harrison wrote:
[color=blue]
> On Thu, 22 Jul 2004 15:04:23 -0400 (EDT), Jim Strathmeyer
> <nospam.invalid@andrew.cmu.edu> wrote:
>[color=green]
> > Under what circumstances would closing a istream object (such as
> > 'in.close()') SEGFAULT?[/color]
>
> When you have a bug in your program. What else?
>
> All the usual suspects, writing past he end of an array, writing through a
> garbage pointer, freeing the same memory twice, etc. etc. All these bugs
> can cause anything to happen.
>
> Bugs rarely have any logic. You can rarely say 'well the symptom is this,
> therefore the bug must be that', at least that sort of intuition only
> comes with much experience.[/color]
....right... but why would a SEGFAULT happen inside a library function? | 
July 22nd, 2005, 05:46 PM
| | | | re: istream segfault
On Thu, 22 Jul 2004 15:24:26 -0400 (EDT) in comp.lang.c++, Jim
Strathmeyer <nospam.invalid@andrew.cmu.edu> wrote,[color=blue]
>
>...right... but why would a SEGFAULT happen inside a library function?[/color]
Most typical reason... because the structures used by the library to
manage the memory free store had been clobbered by any of the kinds of
activity that John mentioned. When trying to return the released memory
formerly used by your stream, the library encounters a pointer to outer
space. | 
July 22nd, 2005, 05:48 PM
| | | | re: istream segfault
"Jim Strathmeyer" <nospam.invalid@andrew.cmu.edu> wrote in message
news:Pine.LNX.4.58-035.0407221523280.8938@unix43.andrew.cmu.edu...[color=blue]
>
> On Thu, 22 Jul 2004, John Harrison wrote:
>[color=green]
> > On Thu, 22 Jul 2004 15:04:23 -0400 (EDT), Jim Strathmeyer
> > <nospam.invalid@andrew.cmu.edu> wrote:
> >[color=darkred]
> > > Under what circumstances would closing a istream object (such as
> > > 'in.close()') SEGFAULT?[/color]
> >
> > When you have a bug in your program. What else?
> >
> > All the usual suspects, writing past he end of an array, writing through[/color][/color]
a[color=blue][color=green]
> > garbage pointer, freeing the same memory twice, etc. etc. All these bugs
> > can cause anything to happen.
> >
> > Bugs rarely have any logic. You can rarely say 'well the symptom is[/color][/color]
this,[color=blue][color=green]
> > therefore the bug must be that', at least that sort of intuition only
> > comes with much experience.[/color]
>
> ...right... but why would a SEGFAULT happen inside a library function?[/color]
If you've done something 'wrong' (such as some of the things
John mentioned) *anywhere* in your program, it could easily
cause corruption anywhere else in your program, including inside
library code. IMO the best way for tracking down a bug whose source
is unknown and/or not easily reprocible is careful, methodical
testing, and selective removal of (relatively large) sections of
code, testing each version. One a large section has been identified
as the culprit, start removing smaller sections of that section.
Good debuggers also help much.
-Mike |  | | | | /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 225,702 network members.
|