Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

callback returns useless error message #5732

Open
p6rt opened this issue Oct 6, 2016 · 5 comments
Open

callback returns useless error message #5732

p6rt opened this issue Oct 6, 2016 · 5 comments
Labels
LTA Less Than Awesome; typically an error message that could be better NativeCall

Comments

@p6rt
Copy link

p6rt commented Oct 6, 2016

Migrated from rt.perl.org#129820 (status was 'open')

Searchable as RT129820$

@p6rt
Copy link
Author

p6rt commented Oct 6, 2016

From @titsuki

In the following example, ` my &ook = sub (Int $piyo) ` has wrong signature (` my &ook = sub (Int $piyo, Num $fuga) ` is a right one)and it returns the error message of "Internal error​: Unwound entire stack and missed handler".
Honestly to say, it doesn't seem to make sense to me and I can't imagine what to do.

* codes *
t/02-callback.t


use v6;
use Test;
use NativeCall;
use lib <lib t>;
use CompileTestLib;

compile_test_lib('02-callback');
my sub doit(&foo_t (int32, num64 --> int32)) is native("./02-callback") { * }

{
    my &ook = sub (Int $piyo) {
        return 0;
    }
    doit(&ook);
}

done-testing;


t/02-callback.c


#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "02-callback.h"

#ifdef _WIN32
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT extern
#endif

int doit(foo_t foo){ foo(10,3.1); }


t/02-callback.h


#if ! defined(HEADER_CALLBACK_H)
#define HEADER_CALLBACK_H

#ifdef __cplusplus
extern "C" {
#endif

typedef int (*foo_t)(
                     int piyo,
                     double fuga
                     );

#ifdef __cplusplus
} /* closing brace for extern "C" */
#endif

#endif /* HEADER_CALLBACK_H */


* results *


$ mi6 test -v t/02-callback.t
==> Set PERL6LIB=/home/itoyota/Programs/p6-Foo/lib
==> prove -e /home/itoyota/.rakudobrew/bin/../moar-nom/install/bin/perl6 -r -v t/02-callback.t
t/02-callback.t .. Internal error​: Unwound entire stack and missed handler
Dubious, test returned 1 (wstat 256, 0x100)
No subtests run 

Test Summary Report


t/02-callback.t (Wstat​: 256 Tests​: 0 Failed​: 0)
  Non-zero exit status​: 1
  Parse errors​: No plan found in TAP output
Files=1, Tests=0,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.45 cusr  0.06 csys =  0.53 CPU)
Result​: FAIL


$ perl6 --version
This is Rakudo version 2016.09-105-g4abc28c built on MoarVM version 2016.09-13-g34c375a
implementing Perl 6.c.

@p6rt
Copy link
Author

p6rt commented Oct 6, 2016

From @geekosaur

On Thu, Oct 6, 2016 at 1​:39 PM, Itsuki Toyota <perl6-bugs-followup@​perl.org>
wrote​:

In the following example, ` my &ook = sub (Int $piyo) ` has wrong
signature (` my &ook = sub (Int $piyo, Num $fuga) ` is a right one)and
it returns the error message of "Internal error​: Unwound entire stack and
missed handler".
Honestly to say, it doesn't seem to make sense to me and I can't imagine
what to do.

I believe this is known. and it's difficult to fix​: you simply can't map
exceptions across languages, so an exception in a Perl callback from a C
function called from Perl can only be caught in the context of the callback
itself. C has no clue about the exception, so you can neither catch it in C
nor have C relay it to the original Perl context. The error is, not very
clearly (or rather, saying it clearly but in terms of internals), saying
this​: it can't find an exception handler in the callback's Perl context
(and, implicitly, it can never reach one outside of the callback's
context). Distilling this down to a short error message is a bit difficult.

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

@p6rt
Copy link
Author

p6rt commented Oct 6, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Oct 6, 2016

From @geekosaur

On Thu, Oct 6, 2016 at 1​:48 PM, Brandon Allbery via RT <
perl6-bugs-followup@​perl.org> wrote​:

I believe this is known. and it's difficult to fix​: you simply can't map
exceptions across languages, so an exception in a Perl callback from a C
function called from Perl can only be caught in the context of the callback
itself. C has no clue about the exception, so you can neither catch it in C

Actually, now that I think about it, there is something that can be done;
not ideal, but the best we could do under the circumstances. Callbacks
should be given default exception handlers that at minimum output the
original exception (which currently is being lost when finding the
exception handler fails) and say they're aborting because there's no way to
pass the exception back through C to the outer Perl scope. Something like​:

  Exception in Perl callback cannot be passed back through native code.
All we can do is die. Sorry.
  Unhandled exception​:
  (actual thrown exception here)

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

@p6rt
Copy link
Author

p6rt commented Oct 7, 2016

From @toolforger

Am 06.10.2016 um 21​:07 schrieb Brandon Allbery via RT​:

Actually, now that I think about it, there is something that can be done;
not ideal, but the best we could do under the circumstances. Callbacks
should be given default exception handlers that at minimum output the
original exception (which currently is being lost when finding the
exception handler fails) and say they're aborting because there's no way to
pass the exception back through C to the outer Perl scope. Something like​:

Exception in Perl callback cannot be passed back through native code\.

All we can do is die. Sorry.
Unhandled exception​:
(actual thrown exception here)

Actually that's the only sane way to deal with such a situation, and
that should be documented behaviour for callbacks.

Essentially, it's a special case of a callback failing for some reason;
any well-designed callback API should offer a way to report back
"failure" in some way, be it via an exception, a return code (plus
hopefully a data block with more info), or whatever. If the API is not
well-designed, the best the callback can do in case of failure is to die
with an error message.

@p6rt p6rt added LTA Less Than Awesome; typically an error message that could be better NativeCall labels Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better NativeCall
Projects
None yet
Development

No branches or pull requests

1 participant