Ticket #1973 (closed bug: fixed)

Opened 11 years ago

Last modified 10 years ago

pbc_merge fails silently

Reported by: rgrjr Owned by: whiteknight
Priority: normal Milestone:
Component: tools Version: master
Severity: medium Keywords: pbc_merge, api
Cc: Language:
Patch status: Platform: all

Description

1. Download the test case tarball from  http://www.rgrjr.com/perl/bug-pbc-merge-110115.tgz, unpack it, and edit the PARROT-HOME macro in the makefile to point to a local Parrot working copy. (It's 310KB, so Trac won't accept it as an attachment.)

2. Run "make" to build and run the test. Here's what the output looks like on my machine (GNU/Linux, openSUSE 11.3):

rogers@rgr> make /usr/src/parrot/parrot -o compiler-structures.pbc compiler-structures.pir /usr/src/parrot/parrot -o emit.pbc emit.pir /usr/src/parrot/parrot -o package-decls.pbc package-decls.pir /usr/src/parrot/parrot -o walker.pbc walker.pir /usr/src/parrot/parrot -o defstruct.pbc defstruct.pir /usr/src/parrot/parrot -o forms.pbc forms.pir /usr/src/parrot/parrot -o top-level.pbc top-level.pir /usr/src/parrot/pbc_merge -o compiler.pbc compiler-structures.pbc emit.pbc package-decls.pbc walker.pbc defstruct.pbc forms.pbc top-level.pbc make: *** [test] Error 1 rogers@rgr>

I have no clue what's going on here, except I did manage to figure out that PackFile_unpack doesn't return on the last file. It seems to be size-related, because dropping one or two of the input PBC files makes it succeed, and it doesn't seem to matter which ones are dropped (hence the size of the test case).

Change History

  Changed 11 years ago by plobsing

  • owner set to whiteknight

This is the result of recent changes to unhandled exception behaviour. Previously, the exception message ("Could not load oplib `%s'") would have been printed.

Fixing this particular error should be easy, however there is a deeper issue. Not having a jump-out point defined appears to violate assumptions of the new code and fails in a manner that is very user unfriendly. Some form of "C assumption violated" mechanism should be involved. I suggest intentionally dereferencing an invalid pointer to force a segfault ("{ int segfault = *(int *)NULL; }").

Assigning to whiteknight, lead developer for API.

follow-up: ↓ 4   Changed 11 years ago by rgrjr

That is curious. AFAICS, the only oplib loaded is "bit_ops", which is part of Parrot. Why would that fail in pbc_merge when it doesn't fail when loaded into parrot? (Given the right parrot, of course, with all the necessary prerequisites.)

  Changed 11 years ago by jkeenan

  • component changed from none to tools

in reply to: ↑ 2   Changed 11 years ago by plobsing

Replying to rgrjr:

That is curious. AFAICS, the only oplib loaded is "bit_ops", which is part of Parrot. Why would that fail in pbc_merge when it doesn't fail when loaded into parrot? (Given the right parrot, of course, with all the necessary prerequisites.)

It is in fact bit_ops that is triggering this error (to play along at home, break on Parrot_ex_throw_from_c_args in your C debugger).

It would appear (strace) that pbc_merge is not checking the correct paths for installed oplibs. This is most likely due to the fact that pbc_merge does not set up a config hash.

follow-up: ↓ 6   Changed 11 years ago by whiteknight

  • status changed from new to assigned
  • platform set to all
  • version changed from trunk to master
  • keywords pbc_merge, api added

This does indeed appear to be related to the embed_api changes. It appears to be an oversight: We changed around the config hash handling, but we never updated pbc_merge to the new system. In 489709a600dc528055eb89df449ddd01d00c7e25 I did the update.

It appears to be working fine for me, but I can't run the complete test case provided by rgrjr. If somebody else can try it out for me, I would appreciate it.

As a bigger problem, it does indeed appear that there is also a problem with the exception handling. pbc_merge doesn't look like it's printing out unhandled exception messages anywhere, so I need to take a closer look at that.

in reply to: ↑ 5   Changed 11 years ago by rgrjr

Replying to whiteknight:

This does indeed appear to be related to the embed_api changes. It appears to be an oversight: We changed around the config hash handling, but we never updated pbc_merge to the new system. In 489709a600dc528055eb89df449ddd01d00c7e25 I did the update.

Excellent; thank you.

It appears to be working fine for me, but I can't run the complete test case provided by rgrjr. If somebody else can try it out for me, I would appreciate it.

I can confirm that the test case I submitted now builds compiler.pbc as expected. (The original "make" target still fails, but I assume that's my problem.)

As a bigger problem, it does indeed appear that there is also a problem with the exception handling. pbc_merge doesn't look like it's printing out unhandled exception messages anywhere, so I need to take a closer look at that.

That will certainly help. ;-} Thanks again.

  Changed 11 years ago by jkeenan

rgrjr,

Do you have continuing concerns in this area? If not, can we close the ticket -- or perhaps open a new one focusing on what still needs to be addressed?

Thank you very much.

kid51

  Changed 10 years ago by whiteknight

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

no further concerns mentioned, I'm closing this ticket.

Note: See TracTickets for help on using tickets.