I have a large Dancer application that crashes rarely with the attached stack trace. I haven’t yet identified any specific code or pattern that triggers the crash; if I restart (perl ./bin/app.pl) and repeat exactly what I was doing prior to the crash, it usually works just fine. Versions: Perl 5.26.2 Dancer 1.3500 Is this a known problem? Solutions? Stack trace: Use of uninitialized value in subroutine entry at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 397. HTTP::Server::Simple::__ANON__("Dancer::Handler::Standalone::NetServer0") called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 342 HTTP::Server::Simple::__ANON__("Dancer::Handler::Standalone::NetServer0", "port", 8080) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 306 HTTP::Server::Simple::run(Dancer::Handler::Standalone=HASH(0x562484f61698)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer/Handler/Standalone.pm line 38 Dancer::Handler::Standalone::start(Dancer::Handler::Standalone=HASH(0x56247b0cf578)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer/Handler.pm line 209 Dancer::Handler::dance(Dancer::Handler::Standalone=HASH(0x56247b0cf578)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer.pm line 496 Dancer::_start() called at ./bin/app.pl line 235 Bad arg length for Socket::sockaddr_family, length is 0, should be at least 2 at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 397. HTTP::Server::Simple::__ANON__("Dancer::Handler::Standalone::NetServer0") called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 342 HTTP::Server::Simple::__ANON__("Dancer::Handler::Standalone::NetServer0", "port", 8080) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 306 HTTP::Server::Simple::run(Dancer::Handler::Standalone=HASH(0x562484f61698)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer/Handler/Standalone.pm line 38 Dancer::Handler::Standalone::start(Dancer::Handler::Standalone=HASH(0x56247b0cf578)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer/Handler.pm line 209 Dancer::Handler::dance(Dancer::Handler::Standalone=HASH(0x56247b0cf578)) called at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/Dancer.pm line 496 Dancer::_start() called at ./bin/app.pl line 235 Thanks in advance!
On Mar 12, 2019, at 12:10 AM, Hermann Calabria <hermann@ivouch.com> wrote:
if I restart (perl ./bin/app.pl) and repeat exactly what I was doing prior to the crash, it usually works just fine.
Are you using a persistent Session store? If so, and emptying it between stopping and restarting the app now makes the symptom reproducible, you know the problem is due to data cached in the Session object. In that case, I’d guess you’ve put “undef” into a variable and are now trying to use it in a context where a defined value is expected. This includes the Dancer::Session::Cookie option: if you’re using that and fail to toss the browser’s cookies between tests, you aren’t starting from a fresh state. *Something* must be persisting between app runs to cause it to have differing behavior from one run to the next, so if it isn’t the Session/Cookie, then it’d have to be your app’s backing data store, whatever that is. If chasing all of the persistence layers in your app doesn’t bring you to a solution, I’d start removing large chunks of code until the problem went away, then perform a binary search on the last chunk removed to pare the problem down to a single line.
Is this a known problem?
When chasing problems in a widely-used infrastructure component like this, always suspect your own code first.
I forgot to mention, this issue –whatever it is -- causes Dancer to die completely, as in the main Dancer event loop crashes, and the process has to be restarted. Sure, it’s probably something my app is doing. However I expect Dancer to be resilient enough to not crash in this manner. Plus the fact that it’s intermittent, your comments re state notwithstanding, make this one particularly difficult to debug without having an intimate understanding of the guts of Dancer. I’m hoping one of the Dancer devs takes a quick look, as in any case, even if my app is causing the problem, there’s likely an opportunity here for improving Dancer. In the meantime I will continue investigating. From: Warren Young Sent: Tuesday, March 12, 2019 1:59 PM To: Perl Dancer users mailing list Subject: Re: [dancer-users] Dancer crashing On Mar 12, 2019, at 12:10 AM, Hermann Calabria <hermann@ivouch.com> wrote:
if I restart (perl ./bin/app.pl) and repeat exactly what I was doing prior to the crash, it usually works just fine.
Are you using a persistent Session store? If so, and emptying it between stopping and restarting the app now makes the symptom reproducible, you know the problem is due to data cached in the Session object. In that case, I’d guess you’ve put “undef” into a variable and are now trying to use it in a context where a defined value is expected. This includes the Dancer::Session::Cookie option: if you’re using that and fail to toss the browser’s cookies between tests, you aren’t starting from a fresh state. *Something* must be persisting between app runs to cause it to have differing behavior from one run to the next, so if it isn’t the Session/Cookie, then it’d have to be your app’s backing data store, whatever that is. If chasing all of the persistence layers in your app doesn’t bring you to a solution, I’d start removing large chunks of code until the problem went away, then perform a binary search on the last chunk removed to pare the problem down to a single line.
Is this a known problem?
When chasing problems in a widely-used infrastructure component like this, always suspect your own code first. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Tue, 12 Mar 2019 15:08:46 -0700 Hermann Calabria wrote:
Sure, it’s probably something my app is doing. However I expect Dancer to be resilient enough to not crash in this manner.
FWIW, I did notice that the crash appeared to happen because of an uninitialized value. Do you have fatal warnings turned on, and could that be one of the causes? I don't know, but does Dancer normally run without fatal warnings, and maybe the problem you encountered wouldn't normally be fatal? Andy
I don’t have fatal warnings turned on. Also, reviewing the stack trace, none of the calls appear to go through the app. The only packages involved are: HTTP::Server::Simple Dancer::Handler::Standalone Dancer::Handler Dancer From: Andrew Beverley Sent: Tuesday, March 12, 2019 3:56 PM To: Perl Dancer users mailing list Cc: Hermann Calabria Subject: Re: [dancer-users] Dancer crashing On Tue, 12 Mar 2019 15:08:46 -0700 Hermann Calabria wrote:
Sure, it’s probably something my app is doing. However I expect Dancer to be resilient enough to not crash in this manner.
FWIW, I did notice that the crash appeared to happen because of an uninitialized value. Do you have fatal warnings turned on, and could that be one of the causes? I don't know, but does Dancer normally run without fatal warnings, and maybe the problem you encountered wouldn't normally be fatal? Andy
On Wed, 13 Mar 2019 08:51:04 -0700 Hermann Calabria <hermann@ivouch.com> wrote:
I don’t have fatal warnings turned on.
Also, reviewing the stack trace, none of the calls appear to go through the app. The only packages involved are:
HTTP::Server::Simple Dancer::Handler::Standalone Dancer::Handler Dancer
Here are lines 396 and 397 of HTTP/Server/Simple.pm (version 0.52): my $remote_sockaddr = getpeername( $self->stdio_handle ); my $family = sockaddr_family($remote_sockaddr); So $remote_sockaddr is undef. It should avoid calling sockaddr_family() in that case.
From: Andrew Beverley Sent: Tuesday, March 12, 2019 3:56 PM To: Perl Dancer users mailing list Cc: Hermann Calabria Subject: Re: [dancer-users] Dancer crashing
On Tue, 12 Mar 2019 15:08:46 -0700 Hermann Calabria wrote:
Sure, it’s probably something my app is doing. However I expect Dancer to be resilient enough to not crash in this manner.
FWIW, I did notice that the crash appeared to happen because of an uninitialized value. Do you have fatal warnings turned on, and could that be one of the causes? I don't know, but does Dancer normally run without fatal warnings, and maybe the problem you encountered wouldn't normally be fatal?
Andy
-- C. Chad Wallace, B.Sc. The Lodging Company http://www.lodgingcompany.com/ OpenPGP Public Key ID: 0x262208A0 +1 250-869-4931 ext. 6251
On Wed, 13 Mar 2019 09:58:54 -0700 Chad Wallace <cwallace@lodgingcompany.com> wrote:
Here are lines 396 and 397 of HTTP/Server/Simple.pm (version 0.52):
my $remote_sockaddr = getpeername( $self->stdio_handle ); my $family = sockaddr_family($remote_sockaddr);
So $remote_sockaddr is undef. It should avoid calling sockaddr_family() in that case.
It looks like Chad is right - it would appear to be a problem with HTTP::Server::Simple. That means (a) it should be reported there, (b) it should only affect you while running Dancer standalone. You could, if you're keen, patch your local HTTP::Server::Simple with a check that the call to getpeername( $self->stdio_handle ) did indeed return something useful, before then passing that to sockaddr_family(), and if not, emit as much potentially-useful debug info as you can, to try to isolate the conditions under which this could happen. Some form of stress-testing might help, too - maybe it's a timing issue, a race condition where another request arrives while a previous one is in a certain state, where the client (or another/previous client) drops its connection right whne the server isn't expecting it, or similar? Cheers Dave P
Hi all, Still (3 months later) struggling with this one. I’m still seeing the occasional crashes, and in addition – and this is new -- tests using Dancer::Test are failing consistency which may be yet another clue. I’ve narrowed the potential culprit to fancy route handling being done by my app. I’m posting here functioning and well-commented code (i.e. works most of the time except when it crashes as previously described) for any comments or thoughts. As an alternative way to fix the problem, I also welcome alternative ways to accomplish what we’re trying to accomplish (as described in comments): use strict; use warnings; use Dancer; =item Each "instance" of the app is accessed via a URL prefix representing each "client". Examples: Various paths within instance for client #1, called "mary": http://www.myapp.com/mary http://www.myapp.com/mary/foo http://www.myapp.com/mary/foo/bar Various paths within instance for client #2, called "susan": http://www.myapp.com/susan http://www.myapp.com/susan/foo http://www.myapp.com/susan/foo/bar The various paths are implemented as Dancer Routes: GET '/instance/...' Examples: POST '/instance/bar/api/users' GET '/instance/foo/bar' We trick Dancer by substituting the instance URL with "/instance". All such trickery is contained within this one file. Here's how it works: 1. Dancer will attempt to match path to anything in ./public, and return file. However, since instance-specific paths will be along the lines of http://www.myapp.com/mary/my.css, no match will occur, since all instance-specific assets are under ./public/instance. 2. Dancer attempts to match by route. Very first route is qr{.*} route (see below). However, before this route runs, hook 'before' will be triggered... 3a. hook 'before' looks for instance URL prefixes (such as "/mary", "/susan" above). If match: - change path to '/instance/..' - if path points to a ./public resource [/instance/(static|cached)], return to qr{.*} immediately - set vars->{'client'} to client id, such as "mary" or "susan" above - return to qr{.*} route 3b. If no match under 3a, return to qr{.*} 4. Back in qr{.*}: - if route path is an instance-specific public asset [/instance/(static|cached)], send it manually using Dancer's send_file() - otherwise pass(), which leads to remaining default Dancer route handling: - if route path matches a remaining Dancer route, that route will be executed - if no matches, Dancer creates 404/not_found error (unless final route is another catch-all for special handling of 404s) =cut any qr{.*} => sub { my $request_path = request->path_info; # Manually send files in ./public/instance/(static|cached) if ( $request_path =~ m{^/(instance/(static|cached)(/.*|\z))} ) { send_file( $1 ); return; # per Dancer docs, route exits after send_file(). return is unnecessary; added for readability. } # causes Dancer to attempt to match to all remaining routes, with path as modified by hook pass(); }; hook 'before' => sub { my $request_path = request->path_info(); # # /instance # (already did all hook_before operations when first entered as /[instance_url], so skip now) # if ( $request_path =~ m{^/instance(/|\z)} ) { return; } # # /[instance_url] # # If match, # 1. converts $request_path & request->path_info to /instance/... # 2. sets $instance # # If no match, returns # my $instance; if ( $request_path =~ m{^/([^/]+)(/.*|\z)} ) { my $url = $1; my $therest = $2; if ( $url =~ /^(mary|susan)$/ ) { # simplified; actual code uses a database $instance = $url; $request_path = "/instance" . $therest; request->path_info( $request_path ); } } if ( !defined($instance) ) { return; } # # /instance (converted from /[instance_url]) # with $instance # # hole for ./instance/(static|cached) if ( $request_path =~ m{^/instance/(static|cached)(/|\z)} ) { return; } # set instance-specific var var instance => $instance; # # Only allow access to specific /instance areas, and in some cases require authentication # # /instance - welcome if ( $request_path =~ m{^/instance/?\z} ) { return; } # /instance/register - Register if ( $request_path =~ m{^/instance/register(/|\z)} ) { return; } # /instance/signedin - Signed-in area (requires authentication) if ( $request_path =~ m{^/instance/signedin(/|\z)} ) { if (!vars->{'not_signed_in'}) { request->path_info( "/instance/register"); } return; } # /instance/(everything else) request->path_info('/instance/error/notfound'); return; }; # # /instance routes # get '/instance' => sub { return "Welcome, ".vars->{'instance'}; }; get '/instance/register' => sub { return "Please register, ".vars->{'instance'}; }; get '/instance/signedin' => sub { return "This is the signed-in area, ".vars->{'instance'}.". You are authenticated"; }; get '/instance/error/not/found' => sub { return "OOPS! 404 Error"; }; dance; Test results: use Dancer::Test; … response_status_is [GET => "/instance"], 200; # ok response_status_is [GET => "/mary"], 200; # fails. Gets 404. response_status_is [GET => "/susan"], 200; # fails. Gets 404. Thoughts/ideas? Thank you!! Hermann From: David Precious Sent: Tuesday, March 19, 2019 6:17 AM To: dancer-users@dancer.pm Subject: Re: [dancer-users] Dancer crashing On Wed, 13 Mar 2019 09:58:54 -0700 Chad Wallace <cwallace@lodgingcompany.com> wrote:
Here are lines 396 and 397 of HTTP/Server/Simple.pm (version 0.52):
my $remote_sockaddr = getpeername( $self->stdio_handle ); my $family = sockaddr_family($remote_sockaddr);
So $remote_sockaddr is undef. It should avoid calling sockaddr_family() in that case.
It looks like Chad is right - it would appear to be a problem with HTTP::Server::Simple. That means (a) it should be reported there, (b) it should only affect you while running Dancer standalone. You could, if you're keen, patch your local HTTP::Server::Simple with a check that the call to getpeername( $self->stdio_handle ) did indeed return something useful, before then passing that to sockaddr_family(), and if not, emit as much potentially-useful debug info as you can, to try to isolate the conditions under which this could happen. Some form of stress-testing might help, too - maybe it's a timing issue, a race condition where another request arrives while a previous one is in a certain state, where the client (or another/previous client) drops its connection right whne the server isn't expecting it, or similar? Cheers Dave P _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Herman, I'm not a Dancer developer, but maybe you could post your test harness as well? Or does your simple test case always fail no matter what? Is there anyway you can simplify your routing, or maybe push all the static stuff to nginx or some other web server, and only pass in the dynamic stuff you need to handle? And looking at your tests, it's not clear to me that you're testing all your complex logic properly. Can you just do the test for /mary/static/my.css, /mary, /mary/static, etc? Just show all the possible options you need to handle for one client and show those results.
From what I recall, it sounds like it works sometimes, but not always. So maybe you can show in your 404 error what was missing to let you get there, not where you expected.
Sorry I'm probably not really asking for anything useful here, but hopefully this will make you re-look at it differently to find the real cause. But again, simplify and document your test cases better with expected and actual results so people can know what expect. And a full contained test app showing the problem would be even better. John
On 3/13/19 4:51 PM, Hermann Calabria wrote:
I don’t have fatal warnings turned on.
Also, reviewing the stack trace, none of the calls appear to go through the app. The only packages involved are:
HTTP::Server::Simple
Dancer::Handler::Standalone
Dancer::Handler
Dancer
Hello Herrmann, at any rate my advise would be to not use dancer standalone at all, especially not in a production environment. With plackup + starman you get a more reliable environment, and you can restrict the lifetime of the workers by using plackup's --max-requests option. That is useful to limit memory growth and other hard to track problems occurring on long running applications. Regards Racke
*From: *Andrew Beverley <mailto:andy@andybev.com> *Sent: *Tuesday, March 12, 2019 3:56 PM *To: *Perl Dancer users mailing list <mailto:dancer-users@dancer.pm> *Cc: *Hermann Calabria <mailto:hermann@ivouch.com> *Subject: *Re: [dancer-users] Dancer crashing
On Tue, 12 Mar 2019 15:08:46 -0700 Hermann Calabria wrote:
Sure, it’s probably something my app is doing. However I expect
Dancer to be resilient enough to not crash in this manner.
FWIW, I did notice that the crash appeared to happen because of an
uninitialized value. Do you have fatal warnings turned on, and could
that be one of the causes? I don't know, but does Dancer normally run
without fatal warnings, and maybe the problem you encountered wouldn't
normally be fatal?
Andy
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. Provisioning with Ansible.
Thanks for the reply and comments. So we only use Dancer::Standalone for development. For production, we use uwsgi (which btw works phenomenally well as compared to Starman). This particular version of the software, including with the latest version of Dancer 1, is not yet in production, so I don’t yet know if we will see this same problem during production. If the problem only surfaces with Dancer::Standalone, I suppose we can live with it…. what I want to avoid is releasing new software into production that has this problem from day 1. I understand uwsgi will simply restart the crashed process, but that’s no way to run at scale, and also the user will experience an error and may not know to just “refresh”. From: Stefan Hornburg (Racke) Sent: Wednesday, March 13, 2019 10:00 AM To: dancer-users@dancer.pm Subject: Re: [dancer-users] Dancer crashing On 3/13/19 4:51 PM, Hermann Calabria wrote:
I don’t have fatal warnings turned on.
Also, reviewing the stack trace, none of the calls appear to go through the app. The only packages involved are:
HTTP::Server::Simple
Dancer::Handler::Standalone
Dancer::Handler
Dancer
Hello Herrmann, at any rate my advise would be to not use dancer standalone at all, especially not in a production environment. With plackup + starman you get a more reliable environment, and you can restrict the lifetime of the workers by using plackup's --max-requests option. That is useful to limit memory growth and other hard to track problems occurring on long running applications. Regards Racke
*From: *Andrew Beverley <mailto:andy@andybev.com> *Sent: *Tuesday, March 12, 2019 3:56 PM *To: *Perl Dancer users mailing list <mailto:dancer-users@dancer.pm> *Cc: *Hermann Calabria <mailto:hermann@ivouch.com> *Subject: *Re: [dancer-users] Dancer crashing
On Tue, 12 Mar 2019 15:08:46 -0700 Hermann Calabria wrote:
Sure, it’s probably something my app is doing. However I expect
Dancer to be resilient enough to not crash in this manner.
FWIW, I did notice that the crash appeared to happen because of an
uninitialized value. Do you have fatal warnings turned on, and could
that be one of the causes? I don't know, but does Dancer normally run
without fatal warnings, and maybe the problem you encountered wouldn't
normally be fatal?
Andy
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. Provisioning with Ansible.
On Wed, 13 Mar 2019 10:34:56 -0700 Hermann Calabria <hermann@ivouch.com> wrote:
Thanks for the reply and comments.
So we only use Dancer::Standalone for development. For production, we use uwsgi (which btw works phenomenally well as compared to Starman).
This particular version of the software, including with the latest version of Dancer 1, is not yet in production, so I don’t yet know if we will see this same problem during production. If the problem only surfaces with Dancer::Standalone, I suppose we can live with it…. what I want to avoid is releasing new software into production that has this problem from day 1. I understand uwsgi will simply restart the crashed process, but that’s no way to run at scale, and also the user will experience an error and may not know to just “refresh”.
Have you been able to reproduce it? The errors you posted indicate the other end of the connection is no longer there. That's probably caused by the user closing the connection (e.g., closing their browser or turning off the computer). If they're not there anymore, you don't need to worry about sending them a response.
From: Stefan Hornburg (Racke) Sent: Wednesday, March 13, 2019 10:00 AM To: dancer-users@dancer.pm Subject: Re: [dancer-users] Dancer crashing
On 3/13/19 4:51 PM, Hermann Calabria wrote:
I don’t have fatal warnings turned on.
Also, reviewing the stack trace, none of the calls appear to go through the app. The only packages involved are:
HTTP::Server::Simple
Dancer::Handler::Standalone
Dancer::Handler
Dancer
Hello Herrmann,
at any rate my advise would be to not use dancer standalone at all, especially not in a production environment.
With plackup + starman you get a more reliable environment, and you can restrict the lifetime of the workers by using plackup's --max-requests option.
That is useful to limit memory growth and other hard to track problems occurring on long running applications.
Regards Racke
*From: *Andrew Beverley <mailto:andy@andybev.com> *Sent: *Tuesday, March 12, 2019 3:56 PM *To: *Perl Dancer users mailing list <mailto:dancer-users@dancer.pm> *Cc: *Hermann Calabria <mailto:hermann@ivouch.com> *Subject: *Re: [dancer-users] Dancer crashing
On Tue, 12 Mar 2019 15:08:46 -0700 Hermann Calabria wrote:
Sure, it’s probably something my app is doing. However I expect
Dancer to be resilient enough to not crash in this manner.
FWIW, I did notice that the crash appeared to happen because of an
uninitialized value. Do you have fatal warnings turned on, and could
that be one of the causes? I don't know, but does Dancer normally run
without fatal warnings, and maybe the problem you encountered wouldn't
normally be fatal?
Andy
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- C. Chad Wallace, B.Sc. The Lodging Company http://www.lodgingcompany.com/ OpenPGP Public Key ID: 0x262208A0 +1 250-869-4931 ext. 6251
On Wed, 13 Mar 2019 08:51:04 -0700 Hermann Calabria wrote:
FWIW, I did notice that the crash appeared to happen because of an uninitialized value. Do you have fatal warnings turned on, and could that be one of the causes? I don't know, but does Dancer normally run without fatal warnings, and maybe the problem you encountered wouldn't normally be fatal?
I don’t have fatal warnings turned on.
Also, reviewing the stack trace, none of the calls appear to go through the app. The only packages involved are:
HTTP::Server::Simple Dancer::Handler::Standalone Dancer::Handler Dancer
Maybe something else has turned fatal warnings on globally, like Moo used to do? I don't know how else you would get the following fatal error, unless something is actually dying with the message "Use of uninitialized value in subroutine entry" Use of uninitialized value in subroutine entry at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 397. Andy
On Thu, 14 Mar 2019 18:35:08 +0000 Andrew Beverley <andy@andybev.com> wrote:
On Wed, 13 Mar 2019 08:51:04 -0700 Hermann Calabria wrote:
FWIW, I did notice that the crash appeared to happen because of an uninitialized value. Do you have fatal warnings turned on, and could that be one of the causes? I don't know, but does Dancer normally run without fatal warnings, and maybe the problem you encountered wouldn't normally be fatal?
I don’t have fatal warnings turned on.
Also, reviewing the stack trace, none of the calls appear to go through the app. The only packages involved are:
HTTP::Server::Simple Dancer::Handler::Standalone Dancer::Handler Dancer
Maybe something else has turned fatal warnings on globally, like Moo used to do?
I don't know how else you would get the following fatal error, unless something is actually dying with the message "Use of uninitialized value in subroutine entry"
Use of uninitialized value in subroutine entry at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 397.
That one's not fatal, but the one after it is. It's a croak from within Socket's XS code. I spent way too much time looking into this yesterday when I was procrastinating something else. :-) -- C. Chad Wallace, B.Sc. The Lodging Company http://www.lodgingcompany.com/ OpenPGP Public Key ID: 0x262208A0 +1 250-869-4931 ext. 6251
On Thu, 14 Mar 2019 11:47:31 -0700 Chad Wallace wrote:
I don't know how else you would get the following fatal error, unless something is actually dying with the message "Use of uninitialized value in subroutine entry"
Use of uninitialized value in subroutine entry at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 397.
That one's not fatal, but the one after it is. It's a croak from within Socket's XS code.
Ah, I see what you mean. I didn't scroll down enough :) Andy
I experienced the error again today, and this time I was careful to note, the user experience is that the server goes away. Poof, gone. There’s no 500 error or anything; it’s as if the server was never there. I restarted the Dancer process, clicked refresh on web browser, and continued normally. I retried the same sequence of user actions that led to the error, but could not replicate. Given the intermittency, and that the error appears to surface on any route, I’m starting to wonder if this is some sort of race condition within the before hook of the app? We do some pretty fancy stuff with the before hook to implement a certain feature of the app; maybe I should post some of that code? In any event, thanks for the continuing discussion. At the risk of encouraging bad habits, Chad, thanks for choosing this issue to procrastinate 😊 From: Andrew Beverley Sent: Thursday, March 14, 2019 11:56 AM To: Perl Dancer users mailing list Subject: Re: [dancer-users] Dancer crashing On Thu, 14 Mar 2019 11:47:31 -0700 Chad Wallace wrote:
I don't know how else you would get the following fatal error, unless something is actually dying with the message "Use of uninitialized value in subroutine entry"
Use of uninitialized value in subroutine entry at /home/hermann/perl5/perlbrew/perls/perl-5.26.2/lib/site_perl/5.26.2/HTTP/Server/Simple.pm line 397.
That one's not fatal, but the one after it is. It's a croak from within Socket's XS code.
Ah, I see what you mean. I didn't scroll down enough :) Andy _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
participants (7)
-
Andrew Beverley -
Chad Wallace -
David Precious -
Hermann Calabria -
John Stoffel -
Stefan Hornburg (Racke) -
Warren Young