ted.byers has asked for the wisdom of the Perl Monks concerning the following question:

I am trying to resolve a bug in which creation of a div on my web age is incomplete, resulting in two other divs not being created. But, while it is obvious the code that creates these other divs is not executed (although code immediately before this code IS executed), due to an error, no error is written to Apache2's error log (in marked contrast to other coding errors I have fixed).

I tried to get at the problem by having the relevant CGI script open a file, and write diagnostic info to that, but when I access the page after doing that, no such file is created. I do use CGI::Carp::DebugScreen, but it does not get exercised in this bug either.

How do I determine where the problem really is, and the cause of it? I have never before encountered a bug for which none of the usual methods of getting error information produce anything.

Thanks

Ted

  • Comment on How to get diagnostic information for a web app when nothing is written to the error log

Replies are listed 'Best First'.
Re: How to get diagnostic information for a web app when nothing is written to the error log
by Corion (Patriarch) on Oct 15, 2015 at 17:12 UTC

    Does your CGI script work when run without the webserver?

Re: How to get diagnostic information for a web app when nothing is written to the error log
by fishmonger (Chaplain) on Oct 15, 2015 at 16:47 UTC

    You can't expect us to help you troubleshoot code which you haven't shown.

    Given the almost non existent info you've given, all I can say is that you need to add some debugging statements around and within the section of code that is supposed to generate the related divs.

Re: How to get diagnostic information for a web app when nothing is written to the error log
by fishmonger (Chaplain) on Oct 15, 2015 at 17:55 UTC
    I tried to get at the problem by having the relevant CGI script open a file, and write diagnostic info to that, but when I access the page after doing that, no such file is created.

    There are 2, possibly more, causes: 1) the opening of and printing to the filehandle is being done in some type of conditional block which is not being triggered or 2) the open call is failing and you don't have any error checking/handling on that call.

Re: How to get diagnostic information for a web app when nothing is written to the error log
by nikosv (Deacon) on Oct 15, 2015 at 18:15 UTC
    more info should be given,else is like a shot in the dark..
    but anyway, how is the div attempted to be created?
    are you using a template or rolling your own html?
    Is the div using any Javascript, so it maybe is not a server problem but a client side one?
    have you tried Firebug and looked into the errors/console panel?
Re: How to get diagnostic information for a web app when nothing is written to the error log
by wollmers (Scribe) on Oct 16, 2015 at 09:40 UTC

    When I have such a problem in foreign code and cannot locate it easily (because the code is badly structured), I insert diagnostic messages. You can send them to client or to the error log of the webserver (print STDERR). So you maybe can debug, if this part of code is reached, how some variables are set.

    If you can still not locate, because the code is deeply nested (Spaghetti Code), then you can factor out subroutines for element groups. Each of the subroutines calls the subroutines for child content, and includes the child content between the opening and closing HTML tags.

    sub invoice { my $invoice_data = shift; my $items_html = invoice_items($invoice_data->{items}); my $invoice_number = $invoice_data->{number}; my $html = <<HTML; <div class="invoice"> <div class="invoice_no">$invoice_number</div> <div class="invoice_items"> $items_html </div><!-- END invoice_items --> </div><!-- END invoice --> HTML return $html; }

    Of course you could also attach HTML comments for BEGIN and END like in the above example. So you can see in the HTML source where the closing div comes from or which is missing.

    With the above small subroutines you can be sure, that they are properly closed. I use these often to repair bogus code. This method which I call "microtemplates" can be applied partially. And the code is fast.