On Tue, 17 May 2005 10:30:42 -0400 Ed Heil <ed@xxxxxxxxxxxxx> wrote:
Hello,
> Hi all. I just installed Tiger on my mac, and am having fun seeing
> how it works with our existing wxPerl application.
I need to buy a copy ASAP...
> We have a class ("LogStderr") which inherits from Wx::PlLog, and
> emits errors to standard error.
>
> The entire class looks like this:
> ------------------------------------------------
> package SharedUtils::LogStderr;
>
> use Wx;
> use base qw( Wx::PlLog);
>
> sub DoLog {
> my ( $self, $level, $msg, $time ) = @_;
> #print STDERR $level, $msg, $time, "\n";
> }
>
> sub DoLogString {
> my ( $self, $msg, $time ) = @_;
> chomp $msg;
> my ( $class, $mode );
> $class = caller(1);
> if ( $class->can( 'debug' ) ) {
> $mode = $class->debug;
> } else {
> $mode = 'NA';
> }
> print STDERR join( '|', scalar(localtime($time)), $class, $msg),
> "\n"
> if $mode or $main::options->{forcedebug};
> }
>
> 1;
> ------------------------------------------------
>
> It's worked great in every other environment we've tried it in, but
> using the builtin tiger build of wxPerl I get the following bizarre
> behavior (this is from a run with -d:Trace) --
>
> >> ./dwlaunch.pl:238: if ( $options->{debug} ) {
> >> ./dwlaunch.pl:239: $logger->SetVerbose(1) if $options->
> {debug};
> >> ./dwlaunch.pl:244: Wx::LogVerbose( "Logging Started...");
> >> /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level/
> Wx.pm:292: my( $t ) = sprintf( shift, @_ ); $t =~ s/\%/\%\%/g;
> wxLogVerbose( $t );
> >> /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level/
> Wx.pm:292: my( $t ) = sprintf( shift, @_ ); $t =~ s/\%/\%\%/g;
> wxLogVerbose( $t );
> >> /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level/
> Wx.pm:292: my( $t ) = sprintf( shift, @_ ); $t =~ s/\%/\%\%/g;
> wxLogVerbose( $t );
> >> SharedUtils/LogStderr.pm:7: my ( $self, $level, $msg, $time )
> = @_;
> >> SharedUtils/LogStderr.pm:12: my ( $self, $msg, $time ) = @_;
> >> SharedUtils/LogStderr.pm:13: chomp $msg;
> >> SharedUtils/LogStderr.pm:14: my ( $class, $mode );
> >> SharedUtils/LogStderr.pm:15: $class = caller(1);
> >> SharedUtils/LogStderr.pm:16: if ( $class->can( 'debug' ) ) {
> >> SharedUtils/LogStderr.pm:19: $mode = 'NA';
> >> SharedUtils/LogStderr.pm:21: print STDERR join( '|', scalar
> (localtime($time)), $class, $msg), "\n"
> Tue May 17 10:20:10 2005|main|Logging Started...
> >> SharedUtils/LogStderr.pm:7: my ( $self, $level, $msg, $time )
> = @_;
> >> SharedUtils/LogStderr.pm:12: my ( $self, $msg, $time ) = @_;
> >> SharedUtils/LogStderr.pm:13: chomp $msg;
> >> SharedUtils/LogStderr.pm:14: my ( $class, $mode );
> >> SharedUtils/LogStderr.pm:15: $class = caller(1);
> >> SharedUtils/LogStderr.pm:16: if ( $class->can( 'debug' ) ) {
> >> SharedUtils/LogStderr.pm:19: $mode = 'NA';
> >> SharedUtils/LogStderr.pm:21: print STDERR join( '|', scalar
> (localtime($time)), $class, $msg), "\n"
> Tue May 17 10:20:10 2005|main|Debug: ../src/common/log.cpp(512):
> assert "wxAssertFailure" failed: DoLogString must be overriden if
> it's called.
> Trace/BPT trap
> You'll notice that it runs through the same code twice, once
> succeeding, and the second time failing with a wxAssertFailure at the
> end of the overridden method with a mysterious error complaining that
> that method is not overridden!
This trace makes no sense to me. I can not see how it can happen...
> Running the same thing with gdb --args gives me:
>
> Tue May 17 10:25:10 2005|main|Logging Started...
> Tue May 17 10:25:10 2005|main|Debug: ../src/common/log.cpp(512):
> assert "wxAssertFailure" failed: DoLogString must be overriden if
> it's called.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x9004a12c in kill ()
> (gdb) bt
> #0 0x9004a12c in kill ()
> #1 0x9c257f54 in wxOnAssert ()
> #2 0x9c29d4ec in wxLog::DoLog ()
> #3 0x9c29c8bc in wxVLogDebug ()
> #4 0x9c29c90c in wxLogDebug ()
> #5 0x9c2584d0 in wxOnAssert ()
> #6 0x9c257fa4 in wxOnAssert ()
> #7 0x9c29d45c in wxLog::DoLog ()
> #8 0x9c29c4a0 in wxVLogVerbose ()
> #9 0x9c29c4f0 in wxLogVerbose ()
> #10 0x004271c4 in XS_Wx_wxLogVerbose ()
> #11 0x970d694c in Perl_pp_entersub ()
> #12 0x970cf274 in Perl_runops_standard ()
> #13 0x9707b6fc in S_run_body ()
> #14 0x9707b358 in perl_run ()
> #15 0x000029b8 in start ()
> #16 0x00002120 in ?? ()
> #17 0x00001fc0 in ?? ()
>
This is even more puzzling: given the current log is a subclass of
Wx::PlLog, the expected backtrace should contain a call to wxPlLog::DoLog,
not wxLog::DoLog!
> Is it possible this is a "debug build" issue -- that the shipped
> version is built with some debugging info and checks/assertions which
> do not always play nicely with wxPerl?
To be honest, I really have no idea.
> It would be a real
> disappointment to find that wxPerl and wxWidgets, now built in to OS
> X, were not actually very usable in that form.
>
> Oddly, I was able to actually get the program working (sort of) by
> typing "continue" in gdb. Then it started displaying assertion
> failures by means of graphical dialogs, and offered a "cancel" button
> to stop displaying them.
Regards
Mattia
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
|
