Slightly off-topic, but...

Discussion in 'C Programming' started by Nick, Nov 15, 2009.

  1. Nick

    Nick Guest

    We were discussing earlier today whether a sequence point in something
    like "continue;" could make any difference.

    While I'm sure it's not that, I'm fascinated by the following output
    from gdb on my crashing program:
    ----
    Program terminated with signal 11, Segmentation fault.
    #0 0x00000000004422b5 in Real_Evaluate (expr=0x7fffeee62968, cache=0x22afd38,
    recurse=false, prevcache=ca_none, lvalue=false, oneitem=false)
    at expression.c:520
    520 break;
    ----
    I'll look at it tomorrow - it's far too late to dig around in core dumps
    now, but I'm deeply fascinated by how a "break;" can cause a
    segmentation fault, I've never seen anything like it before (the first
    thing to do will be to turn optimisation off!).
    --
    Online waterways route planner: http://canalplan.org.uk
    development version: http://canalplan.eu
    Nick, Nov 15, 2009
    #1
    1. Advertising

  2. Nick

    Eric Sosman Guest

    Nick wrote:
    > We were discussing earlier today whether a sequence point in something
    > like "continue;" could make any difference.


    I don't see how it could. As far as I can tell, there
    will be a sequence point immediately before `continue' in
    any context where it can appear. And since `continue' itself
    introduces no side-effects, no further sequence point is needed
    to separate those non-existent side-effects from whatever is
    executed next.

    Also, the Standard doesn't appear to specify a sequence
    point in or after `continue'.

    > While I'm sure it's not that, I'm fascinated by the following output
    > from gdb on my crashing program:
    > ----
    > Program terminated with signal 11, Segmentation fault.
    > #0 0x00000000004422b5 in Real_Evaluate (expr=0x7fffeee62968, cache=0x22afd38,
    > recurse=false, prevcache=ca_none, lvalue=false, oneitem=false)
    > at expression.c:520
    > 520 break;
    > ----
    > I'll look at it tomorrow - it's far too late to dig around in core dumps
    > now, but I'm deeply fascinated by how a "break;" can cause a
    > segmentation fault, I've never seen anything like it before (the first
    > thing to do will be to turn optimisation off!).


    It's quite likely that the fault occurs "near" the `break',
    but that the optimizer's rearrangement of the code disguises
    the actual location (we usually sneer at optimizers that give
    line boundaries too much deference). I hope for your sake
    that the fault is reproducible even with optimization off ...

    --
    Eric Sosman
    lid
    Eric Sosman, Nov 15, 2009
    #2
    1. Advertising

  3. Nick

    Nick Guest

    Eric Sosman <> writes:

    > Nick wrote:
    >> We were discussing earlier today whether a sequence point in something
    >> like "continue;" could make any difference.

    >
    > I don't see how it could. As far as I can tell, there
    > will be a sequence point immediately before `continue' in
    > any context where it can appear. And since `continue' itself
    > introduces no side-effects, no further sequence point is needed
    > to separate those non-existent side-effects from whatever is
    > executed next.
    >
    > Also, the Standard doesn't appear to specify a sequence
    > point in or after `continue'.
    >
    >> While I'm sure it's not that, I'm fascinated by the following output
    >> from gdb on my crashing program:
    >> ----
    >> Program terminated with signal 11, Segmentation fault.
    >> #0 0x00000000004422b5 in Real_Evaluate (expr=0x7fffeee62968,
    >> cache=0x22afd38, recurse=false, prevcache=ca_none, lvalue=false,
    >> oneitem=false)
    >> at expression.c:520
    >> 520 break;
    >> ----
    >> I'll look at it tomorrow - it's far too late to dig around in core dumps
    >> now, but I'm deeply fascinated by how a "break;" can cause a
    >> segmentation fault, I've never seen anything like it before (the first
    >> thing to do will be to turn optimisation off!).

    >
    > It's quite likely that the fault occurs "near" the `break',
    > but that the optimizer's rearrangement of the code disguises
    > the actual location (we usually sneer at optimizers that give
    > line boundaries too much deference). I hope for your sake
    > that the fault is reproducible even with optimization off ...


    It turned out to be terribly boring but a bit strange and inexplicable.
    I noticed that as I added printf debugging lines it moved up and down
    and didn't reflect the actual changes to the code. I deleted the core
    file and let it regenerate itself and it pointed to the actual bug miles
    and miles away.
    --
    Online waterways route planner: http://canalplan.org.uk
    development version: http://canalplan.eu
    Nick, Nov 16, 2009
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Kraus
    Replies:
    1
    Views:
    992
  2. John O'Conner
    Replies:
    1
    Views:
    470
    totojepast
    Jan 30, 2004
  3. PowerSlave2112

    A Legal Question (slightly off-topic)

    PowerSlave2112, Jan 25, 2005, in forum: HTML
    Replies:
    6
    Views:
    490
    Starshine Moonbeam
    Jan 26, 2005
  4. Gaijinco

    Recursion (slightly off-topic)

    Gaijinco, Nov 20, 2005, in forum: C++
    Replies:
    2
    Views:
    282
    John C
    Nov 20, 2005
  5. Ken Fine
    Replies:
    3
    Views:
    366
    Steven Cheng [MSFT]
    Jun 23, 2008
Loading...

Share This Page