@Fab

Actually, catching even simple c++ exceptions is a problem on AOS4:

http://www.amigans.net/?function=viewcomments&threadid=147

When the main task has some try/catch-block then it could be a cause of an error.

regards,
nexus

_________________
dye 'em black!

double post

Last edited by nexus on 01-Mar-2011 at 01:40 PM.

_________________
dye 'em black!

@nexus

But we're not using shared objects, what was the problem you had, right?

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

ah, sorry, u're right.
Please, forget my stupid comment :)

nexus

_________________
dye 'em black!

@Deniil715, nexus, fab

I just do search in whole owb-src *.cpps on the "catch" world, and found only 2 files which are actually use that stuff. That files are:

BAL/Memory/WTF/BCFastMalloc.cpp
JavaScriptCore/wtf/fastmalloc.cpp

In both files actual "catch" block are:

Quote:

static inline void* cpp_alloc(size_t size, bool nothrow) { for (;;) { void* p = do_malloc(size); #ifdef PREANSINEW return p; #else if (p == NULL) { // allocation failed // Get the current new handler. NB: this function is not // thread-safe. We make a feeble stab at making it so here, but // this lock only protects against tcmalloc interfering with // itself, not with other libraries calling set_new_handler. std::new_handler nh; { SpinLockHolder h(&set_new_handler_lock); nh = std::set_new_handler(0); (void) std::set_new_handler(nh); } // If no new_handler is established, the allocation failed. if (!nh) { if (nothrow) return 0; throw std::bad_alloc(); } // Otherwise, try the new_handler. If it returns, retry the // allocation. If it throws std::bad_alloc, fail the allocation. // if it throws something else, don't interfere. try { (*nh)(); } catch (const std::bad_alloc&) { if (!nothrow) throw; return p; } } else { // allocation success return p; } #endif } }

Usage of "fast malloc" are enabled in our sources for now (it can be disabled as well), so for now we use it. Maybe we need try to disable it and test (just to be sure, that its not c++ extensions related at all).

I also do search in the ra-bin and in the mui-bin and found, that in ra-bin we not have at all any "fastmalloc" words, only "malloc" , while in mui-owb (on morphos native version, and on our current port) we have "fastmalloc" words. What mean, that Joerg not use FAST_MALLOC for ra-owb , and maybe there is was any reassons for ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

This code is not used.

And yes, Reaction OWB also uses Fastmalloc. The alternative is a complex memory management done in webkit itself, using threads to scavenge free memory, and relying on pthreads & co.

Last edited by Fab on 01-Mar-2011 at 04:14 PM.

@Fab & Kas1e

Just a thought, how about PushMethods and its counterparts, KillPushMethods and such?

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@kas1e

A little addendum about using -g when compiling:

Because of the potentially large size of the executable when using -g, what you can do is strip it, e.g. 'strip -o OWB OWB.debug' (creating the stripped OWB file from OWB.debug) and keep the original OWB.debug binary somewhere while using and distributing the stripped OWB.

When a crash happens, the offsets obtained from the stripped binary will be the same as in the original binary, so if the stack trace shows
module OWB at 0xXXXXXXXX (section 1 @ 0x1234) you can then use
'Addr2line -e OWB.debug 1234 -j .text'
to get the filename and line no. e.g. "/DH1/Projects/OWB/browser.c:238"

Now if I remember correctly what SSolie taught me, it's actually the instruction *before* the one at line 238 that would be the culprit.

Also keep in mind that if the stack trace starts with some other module e.g. kickstart/kernel, with OWB further down the list, it is likely that OWB fed some invalid values to a kernel function and with the offset from OWB you'd probably find some IExec->function() was called right before that offset

So far there hasn't been a fatal bug in my code that I haven't been able to locate with -g and addr2line so it's proved to be very helpful.

Last edited by AlexC on 04-Mar-2011 at 02:02 PM.

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation

@AlexC
Yep, thanks for info. I know all that stuff already, and with such hardcore bugs all that -g and addr2line not so helpfull. There is only one solution : disabling of parts and found step by step the problems. We just for now drop it to the final end, when all the other problems will be fixed.

Btw, its even possible to found a crash via stack trace, even without -g : by using of objdump. Its of course will be a bit harder (i.e. not exactly line on which crash happens, like with -g/addr2line), adressing will have a bit different offset, but for example on morphos some coders do it like this : just objdump without any -g stuff. But yeah, for sure -g/addr2line are better. Sadly that its all not helpfull when you have no stack-trace at all.

Last edited by kas1e on 04-Mar-2011 at 03:20 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@all

About mui-owb progress:

Process class are done and working ! It was done by Tboekel (Slash's work was not finished, but still his work was helpfull as well). Process uses for font-generation on first running for splash window, which have gauge progress of font generation (To make it looks normal for users, not just some "silent-waiting-dunno-what-happens-now"). That is pretty good to have visually. So, one more problem less.

For those who will say later that port of owb its "only rewrite mui4 to mui3" - we also change some code related to usage of process class of OWB itself (the problems was with different memory-managmen with proceses/task on os4).

Related to random lockup: that problem we will leave for the end, when all the other more easy bugs will be fixed (which i think now are really few).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Really good news

@kas1e Quote:

There is only one solution : disabling of parts and found step by step the problems.

It's a solution but not the only one, and it sounds rather time consuming as you'd have to recompile the code each time.

If it locks up so hard that the reaper can't even output anything on the serial port, your best bet is to boot with the debug kernel, launch OWB, switch the debug level to 10 and after the lockup watch what last came out on your serial terminal. If nothing conclusive got printed when it crashed, try again with level 12, 15, and even 20 if needed. You'll get a lot of debug output and the machine will run slower but you'll definitely have the offending action show up right before the lockup.

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation

@kas1e

Very exciting looking forward to the first release!

_________________
Amiga A1200T - TF1260 - R9200 - Indivision AGA MK3
Amiga A500 - PiStorm EMU68
Pegasos 2 G4 - AmigaOS 4.1 FE / MorphOS 3.16

@AexC
Quote:

If it locks up so hard that the reaper can't even output anything on the serial port, your best bet is to boot with the debug kernel, launch OWB, switch the debug level to 10 and after the lockup watch what last came out on your serial terminal. If nothing conclusive got printed when it crashed, try again with level 12, 15, and even 20 if needed. You'll get a lot of debug output and the machine will run slower but you'll definitely have the offending action show up right before the lockup.

Sounds interesting !

Will try with 10 and then as you say up to 20. Maybe it will give me more info about.

Last edited by kas1e on 05-Mar-2011 at 01:20 PM.
Last edited by kas1e on 05-Mar-2011 at 09:02 AM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@alexc
Can i somehow speed up output via serial , or i limited by 115200 for all the times ?

I do tests with debuglevel 10 and 11. With 10 all works fast, with 11 pretty slow (hardly can open normally any site, but i still manage to crash it on level 11 as well). But on level 12, i just can't open any site at all (i.e. i think i can, but it will take about 5 minuts just for starting to load site, because of all those tons of debug output, which slowdown all the stuff).

@all
Anyway, there is crashlogs:

crashlog with debuglevel 10 - 250kb
crashlog with debuglevel 11 - packed, 350 kb in archive, 5.7 mb unpacked.

Both are done after reboot of os, and catch all the stuff from the running to crash. So there is tons of os-initialisation code at begining, and better do search on "crash" word for start point, on on word "mui" or just on word "muiowb_aos4_alpha" which will mean that handling of binary starting here.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e
Quote:

About mui-owb progress: Process class are done and working ! It was done by Tboekel (Slash's work was not finished, but still his work was helpfull as well). Process uses for font-generation on first running for splash window, which have gauge progress of font generation (To make it looks normal for users, not just some "silent-waiting-dunno-what-happens-now"). That is pretty good to have visually. So, one more problem less. For those who will say later that port of owb its "only rewrite mui4 to mui3" - we also change some code related to usage of process class of OWB itself (the problems was with different memory-managmen with proceses/task on os4). Related to random lockup: that problem we will leave for the end, when all the other more easy bugs will be fixed (which i think now are really few).

Nice not to just hear about random-lock troubleshooting

_________________
SamFlex Complete 800Mhz System + AmigaOS 4.1 Update 4
Amiga 2000 DKB 2MB ChipRam GVP G-Force040 Picasso 2 OS3.9 BB2
AmigaCD 32

@AlexC

Quote:

boot with the debug kernel, launch OWB, switch the debug level to 10 and after the lockup watch what last came out on your serial terminal

I'm really interested to have a complete explanation about this point.

- what is a debug level 10 and how having a serial terminal with one computer ?


This is for my side testing programs and send more than a crashlog when necessary.

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

@Mrodfr

Quote:

- what is a debug level 10

You can read about it in the Sys:Documentation/Kernel/KDebug.readme. There is part aboug debug level:

Quote:

debuglevel - Set the verbosity of debug output of the kernel. 0 means no output, 5 is low (only warnings and critical errors), 10 is verbose (more information), and 20 means it will log every function entry and exit in the kernel.

Quote:

and how having a serial terminal with one computer ?

If you want to see output done to serial on aos4 (i.e. without any terminal programs and cables), you can use "sashimi". But very offten it will just hangs, and you will see nothing, because when heavy crash happens, whole os crashes , and programms like sashimi only redirect buffer to the console => what mean usage of more resources of OS, which already in bad-crash-state => hangs without any output on screen.

For that reassons developers use one more computer, which they connect with amiga-hw by null-modem cable, and all the debug output going to serial (as i read on amigans.net, Troels say that he see that someone use serial-2-usb cable as well). For me personally all that "serial debugging" its need only now, when we have such strange crash. But before, plain GR was enough.

The information in the serial, are the same as you have when you do "dumpdebugbuffer" in the console, or what you will have on the screen if you will use "sashimi". The only pluse, that you got it on another computer, where you have no problems with crashed tasks and freezed aos, and you can normally read all the debug output (which you cant read usually when you have freeze).

All those debug levels, only allow you to see more low-level details, which usually mean nothing for most of developers, but can be more or less helpfull when you not have stack-trace at all, and when developer know aos very-very-well. Because if not, then that information will make no sense for him as well.

In our situation, we not have stack-trace at all, and enabling of debug-level, only add more and more information about processes which happens on the moment of crash (for which understanting as i say, need to be real programmer and know how os works at low-level).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@Mrodfr

Here for faster boot/reboot times I set the level to 0 and disable serial output in uboot by setting the os4_commandline variable to:

debuglevel=0 serial=0 MUNGE

Then once I want to test something, just before I perform some operation which leads to a crash I redirect the debug output to the serial port:

shell> kdebug "console serial"

and then raise the level to 10 with:

shell> kdebug "debuglevel 10"

To capture the serial output you definitely need a separate device, it doesn't have to be a full blown computer, it can be any old pocket computer/PDA with an RS-232 port and term program, or a serial buffer (but that's pricey).

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation

@kas1e

Eeek 96'000 lines of log to read... Well, I read it all and here's what I found:

Quote:

[HAL_DfltTrapHandler] *** Warning: Fatal exception in task 0x66853DC0 Instruction pointer: 0x00000000 Crashed process: owb (0x66853DC0) ISI verbose error description: Instruction fetch in non-execute segment

So the code tried to jump to an instruction at address 0.
Unlike a DSI which usually happen with wrong or uniitialized pointers, this can be caused by a number of things.

I'll try to go back up that log after I've gotten some sleep

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation