Ticket #1745 (closed bug: fixed)

Opened 11 years ago

Last modified 11 years ago

profiling runcore fails with NQP

Reported by: pmichaud Owned by: cotto
Priority: normal Milestone:
Component: core Version: 2.6.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


At cotto++'s urging, I tried the profiling runcore on NQP today and immediately ran into some problems. Here's the summary:

pmichaud@plum:~/nqp-rx$ parrot_install/bin/parrot nqp.pbc --target=pir src/NQP/Actions.pm >actions.pir # works
pmichaud@plum:~/nqp-rx$ parrot_install/bin/parrot -R profiling nqp.pbc --target=pir src/NQP/Actions.pm >actions.pir # fails
elements() not implemented in class 'ParrotInterpreter'
current instr.: 'parrot;Regex;Cursor;' pc 0 (src/Regex/Cursor.pir:22)
... call repeated 1 times

PROFILING RUNCORE: wrote profile to parrot.pprof.6711
Use tools/dev/pprof2cg.pl to generate Callgrind-compatible output from this file.


Change History

Changed 11 years ago by cotto

  • owner set to cotto

Changed 11 years ago by nwellnhof

I once had similar problem with the profiling runcore and I think it's caused by recursive function calls.

Changed 11 years ago by pmichaud

As another datapoint -- the profiling runcore fails during load_bytecode of P6object.pbc (r48825):

pmichaud@orange:~/parrot/trunk$ cat z.pir
.sub 'main' :main
    load_bytecode 'P6object.pbc'
    say 'alive'
pmichaud@orange:~/parrot/trunk$ ./parrot -R profiling z.pir
Segmentation fault

Hope this helps.


Changed 11 years ago by cotto

This bug started appearing when dynop_mapping was merged. Using a version of nqp-rx compatible with r48411 to run parrot -Rprofiling nqp.pbc --target=pir src/NQP/Actions.pm >actions-prof.pir (in this case nqp-rx cf03cdb7) works fine at r48411 but fails at r48412 in the same way pmichaud described above. I'll dig through the merge commit and see if I can find something useful.

Changed 11 years ago by plobsing

Here's what's happening (AFAICT):

  • The exception (segfault, ParrotInterp.elements not impl, etc...) is happening because ADD_OP_VAR_PART() in src/pmc/sub.c:Parrot_Sub_get_line_from_pc is looking at bogus bytecode.
  • This is happening in the profiling runcore code *after* the returncc from runtime/parrot/library/P6object.pir:onload.
  • The bogus bytecode is comming from a bogus context set up by load_bytecode. This comes from r41115 as a fix for TT #150.

Here's how one might fix the problem:

  • figure out how to denote and detect bogus contexts and ignore them properly in introspection code


  • figure out how to avoid using bogus contexts

Changed 11 years ago by cotto

I'm strongly in favor of figuring out how to obviate the bogus contexts. We have plenty of hacks in Parrot without adding another one. I'll see if I can do something on that front.

Changed 11 years ago by cotto

A third possibility exists: instead of creating a half-valid dummy context, create a full pcc sub with the right hll, context, ns, etc. and call that. It would slow down library loading by one additional pcc call/return, but that doesn't need to happen very often. I'm not sure if this could be done in a sane manner, but if we always want load_bytecode to happen in the 'parrot' HLL, this way seems like it'd break the fewest reasonable assumptions which a piece of code would make about the state of a running interpreter.

That said, I don't know if this is feasible or practical. Suggestions are welcome.

Changed 11 years ago by cotto

Happily plobsing concluded that his analysis was incorrect and committed a fix in r49437. Unhappily running nqp under the profiling runcore now fails with a gc assertion failure. My next task is to track down what's broken and get nqp-rx to build with the profiling runcore, after which I'll close this ticket.

Changed 11 years ago by cotto

  • status changed from new to closed
  • resolution set to fixed

Thanks for reporting this. After bacek's help finding a second bug, the profiling runcore is fixed as of r49473. I've tested both Parrot's built and nqp-rx's build and test suite with the profiling runcore hardcoded as the default, and both are successful. This ticket is now closed and the profiling runcore should be much more useful. I'm also running Rakudo's build and spectest under the same conditions and will file a ticket if I break those.

Note: See TracTickets for help on using tickets.