Opened 7 months ago

Closed 6 months ago

#14947 closed bug (fixed)

internal error: Invalid object *c in push()

Reported by: varosi Owned by:
Priority: high Milestone: 8.4.2
Component: Profiling Version: 8.4.1
Keywords: Cc: bgamari
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Steps to reproduce on Windows 10 x64:

stack --version
Version 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0

git clone https://github.com/varosi/cgraytrace.git
cd cgraytrace
git checkout 8c9499e4f3b1ba18b71e499667e865bb6db61856
stack build --profile
stack exec --rts-options="-hr" -- cgraytrace-exe

Rendering to sample.png...
cgraytrace-exe.EXE: internal error: Invalid object *c in push()
     (GHC version 8.4.1 for x86_64_unknown_mingw32)
     Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Change History (12)

comment:1 Changed 7 months ago by varosi

Operating System: Unknown/MultipleWindows

comment:2 Changed 7 months ago by RyanGlScott

Architecture: x86_64 (amd64)Unknown/Multiple
Operating System: WindowsUnknown/Multiple

I can also reproduce this on Linux.

One thing that would help enormously in debugging this is producing a more minimal example that has, well, minimal dependencies.

Last edited 7 months ago by RyanGlScott (previous) (diff)

comment:3 Changed 7 months ago by varosi

Pushed varosi/ghc84_bug branch with lot less dependencies (mainly without Yesod). Is it enough?

Last edited 7 months ago by varosi (previous) (diff)

comment:4 Changed 7 months ago by RyanGlScott

Well, somewhat :) But it still has several bulky dependencies, such as vector, linear, dimensional, and JuicyPixels.

I suspect there's a small kernel of code that's causing this panic, but I don't know how to sort through all of the scaffolding in place to find it at present. Since you know this codebase far better than I do, any useless code you can remove ("useless" meaning "I can still trigger the panic without it") would be of invaluable help here.

comment:5 Changed 7 months ago by varosi

I'll try to remove some dependencies, but vector, linear and dimensional are core parts of the project and cannot be removed easily without rewriting everything.

btw, on GHC 8.2.2 (master branch) there is no problem.

comment:6 Changed 7 months ago by RyanGlScott

Cc: bgamari added

While I'm no closer to minimizing the program, I believe I've found the commit that caused this: 4bfff7a507b5807736e9c6ce9814a9cfa60faeff (rts: Don't default to single capability when profiled).

Ben, do you have any idea what might be happening here? I don't know how to interpret this error message.

comment:7 Changed 7 months ago by RyanGlScott

As an experiment, I built GHC against that commit using this patch:

  • rts/RetainerProfile.c

    diff --git a/rts/RetainerProfile.c b/rts/RetainerProfile.c
    index 7a9b9cc..c6eff0a 100644
    a b push( StgClosure *c, retainer c_child_r, StgClosure **first_child ) 
    442442{
    443443    stackElement se;
    444444    bdescr *nbd;      // Next Block Descriptor
     445    char *barf_me;
    445446
    446447#if defined(DEBUG_RETAINER)
    447448    // debugBelch("push(): stackTop = 0x%x, currentStackBoundary = 0x%x\n", stackTop, currentStack
    push( StgClosure *c, retainer c_child_r, StgClosure **first_child ) 
    633634    case IND:
    634635    case INVALID_OBJECT:
    635636    default:
    636         barf("Invalid object *c in push()");
     637        asprintf(&barf_me, "Invalid object *c in push(): %d", get_itbl(c)->type);
     638        barf(barf_me);
    637639        return;
    638640    }

And this is what I received after running cgraytrace-exe built with this patched GHC:

Rendering to sample.png...
cgraytrace-exe: internal error: Invalid object *c in push(): 37
    (GHC version 8.5.20171211 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

It looks like 37 corresponds to the BLOCKING_QUEUE closure type. push() does not have a case in its giant switch statement for BLOCKING_QUEUE, which at least explains why it falls through.

Last edited 7 months ago by RyanGlScott (previous) (diff)

comment:8 Changed 7 months ago by Ben Gamari <ben@…>

In 9a00bfba/ghc:

rts/RetainerProfile: Dump closure type if push() fails

While investigating #14947, I noticed that the `barf`ed
error message in `push()` doesn't print out the closure type that
causes it to crash. Let's do so.

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: alexbiehl, rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4525

comment:9 Changed 7 months ago by RyanGlScott

Milestone: 8.4.2
Priority: normalhigh

Since this is a regression from 8.2, I'm opting to change the milestone and priority. Do change if you feel this isn't warranted.

comment:10 Changed 6 months ago by Ben Gamari <ben@…>

In d5f6d7a0/ghc:

rts/RetainerProfile: Handle BLOCKING_QUEUES

push() considers BLOCKING_QUEUES to be an invalid closure type which
should never be present on the stack. However, retainClosure made no
accomodation for this and ended up pushing such a closure. This lead
to #14947.

Test Plan: Validate

Reviewers: simonmar, erikd

Reviewed By: simonmar

Subscribers: thomie, carter, RyanGlScott

GHC Trac Issues: #14947

Differential Revision: https://phabricator.haskell.org/D4538

comment:11 Changed 6 months ago by bgamari

Status: newmerge

comment:12 Changed 6 months ago by bgamari

Resolution: fixed
Status: mergeclosed
Note: See TracTickets for help on using tickets.