@kas1e

http://archive.tivocommunity.com/tivo-vb/history/topic/32581-1.html

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@kas1e

edit the kickstart file, renaming the kernel entry in kernel.debug and add "munge" after where you've already added "serial" to see the debug log

_________________
Massimiliano Tretene, ACube Systems, Soft3

@NutsAboutAmiga

For that line
Quote:

MODULE Kickstart/kernel.debug munge

Have syntax error (i think its about "munge") world , but kernel.debug loads fine, dunno through with "mungwall" or without.

@samo79

Trying ryght now to wait 10 minuts on google. And them, type something, it found some, then press on any link - lockup.

Can you detect time exactly, i mean if it for you really 5 minuts + type in google "test" , then enter and crash ?

Because if for you it take 5 minuts, and for me 10 then imho we have different sze of memory (i have 1gb).

@m3x
Aga , got it now, kernel.debug + kdebug "console serial munge".

Last edited by kas1e on 27-Feb-2011 at 02:59 PM.

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

@kas1e

I believe that m3x means adding MUNGE to the os4_commandline uboot variable.

E.g. in uboot prefs (or with 'C:nvgetvar os4_commandline') I see:

debuglevel=0 serial=0 MUNGE

_________________
AlexC's free OS4 software collection

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

@AlexC

I understand his phrase:

Quote:

and add "munge" after where you've already added "serial" to see the debug log

Like add that to my 'kdebug "console serial munge"' line (which i put to startup, to redirect all the output to serial). I think its mean the same ?

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

kernel.debug doesn't exist in OS4.1 Update 1 (for sam440 anyway). Is this a mistake? OS4.1 Update 2 didn't include any new kernel so naturally no new kernel.debug either.

Edit: Yeah, looks like kdebug is used for this now. Did that exist before Update 1?

Last edited by MickJT on 27-Feb-2011 at 03:38 PM.

@m3x

With debug / munge all the same. Same crash (mean that in the crash i have the same info as without debug/munge, and no difference at all in the crash-info).

@samo79

What i notice as well: just run owb, go to google, wait 10 minuts, then just by fastlinks trying to load 3-4 sites, and crash.

Last edited by kas1e on 27-Feb-2011 at 04:14 PM.

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

@kas1e

did you actually read what Max (m3x ) wrote? (post #646)

The MUNGE option, is not the soluton to your crashes. It replaces/adds mungwall you are using (that you must remove)

Here what he suggested few post above:

"if you have a kernel.debug, you may try adding the "munge" option to the os4_commandline and check if the crashlog show something different "

Last edited by Framiga on 27-Feb-2011 at 04:10 PM.

_________________

@Framiga

Quote:

did you actually read what Max (m3x ) wrote? (post #646)

You trying to be smart-ass or helpfull ? Sounds a bit smart-ass kind.

Quote:

The MUNGE option, is not the soluton to your crashes. It replaces/adds mungwall you are using (that you must remove)

Where i say that its should be solution for my crashes ?

Quote:

Here what he suggested few post above: "if you have a kernel.debug, you may try adding the "munge" option to the os4_commandline and check if the crashlog show something different "

And ? If i say "crash the same" , its not mean that it crahses the same and i wait that it will never crashes, its mean that its produce for me the same crash with the same info as without munge . I.e. no difference. I think everyone understand that as well who trying to help here. But i will edit post for m3x , just to avoid more answer of this kind

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

@samo79

I start to think that its still "somehow to sites related". I.e. when you go to google.com and wait 10 minuts, then start to go to any other sites => lockup.

If you go for example at "aros-exec.org" (which for now have nothing on the page, only login window), then wait 10 minuts, then, you can browse the net for next 10 minuts before crash !

What make me think, that some "normal" pages have something, which cause such trashing. Maybe they have javascript (in which code, we also do some changes (was morphos specific) and pretty easyly can ####s here) ) or maybe its related to strings (for title, name of site, etc).

Will be cool now to test just like this:

-- going to 100% non-java site (no java script, not java of any kind). Wait some time, start browse the net (going to google, etc) and detect will lockup happens at this time , or after 10 mins more.

-- going to site which have java-sript stuff ,but to some small one, wait for 10 mins, and start to browse the net (going to google, etc).

If there will be difference, and if after non-jawa site we can use net for 10 mins more, then its very possible related to some "javascriptcollector.cpp" code (which have morphos specific parts, which we a bit change as well).

Last edited by kas1e on 27-Feb-2011 at 04:25 PM.

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

@kas1e

You should try that Forbid() thing.

If OWB uses multiple tasks/threads and there is some thread safety problem in functions like malloc/free (or c++ new/delete) this can cause mem trashing like effects.

Or if it's possible to disable some "do things in separate thread" (networking?) stuff try that.

@Georg
Quote:

You should try that Forbid() thing.

Yeah, thanks for suggestion, i just not answer on your message before because leave it for "hard times"

Quote:

If OWB uses multiple tasks/threads and there is some thread safety problem in functions like malloc/free (or c++ new/delete) this can cause mem trashing like effects.

Originally mui-owb use 3 task/thread stuff: Timer task , WebIcons task and Network Threading.

For now we have disable Webicons thread and netwrok threading, so all in single mode, except timer.

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

@kas1e

How much stack are you using ? Have you tried with bigger stack ?

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Tomppeli

Quote:

#ifdef __amigaos4__ static const char * __attribute__((used)) stackcookie = "$STACK: 1000000"; #endif

Did't try more, but imho 1.000.000 should be fine ?

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

@kas1e

Our current OWB uses half amount of that but I don't know if MUI uses stack or not and how much. You can test what ever amounts you want always.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Tomppeli

Checked with stack 3.000.000 - the same crash.

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

@kas1e

It looks like you finally got stack trace and it's DSI instead of ISI this time: crash2_nomemguard.txt. I'm not PPC assembler expert but the last operation is "lbz r10,0(r4)" so if the last register is used as the address register (in that lbz command) then check the register dump and you'll find a value "00000081" which, I think, can't be a legal value. Which means there's uninitalized memory pointer somewhere.

The last stuff is Z22get_accepted_languagesPcm() before newlib.library in the stack trace but before that there's a lot of timer related stuff.

One version of OWB already works on this platform so it can't be OWB core itself. Then you say it can't be MUI because MUI version works already on another platform. But you guys have put a lot of effort to switch from MUI4 to MUI3 so you have a lot of different code.

Quote:

Checked with stack 3.000.000 - the same crash.

No stack related problems then, I guess.

Last edited by Tomppeli on 27-Feb-2011 at 05:57 PM.
Last edited by Tomppeli on 27-Feb-2011 at 05:56 PM.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Tomppeli

Quote:

Which means there's uninitalized memory pointer somewhere.

That sounds pretty logical, but there is thousands of pointers :(


Quote:

The last stuff is Z22get_accepted_languagesPcm() before newlib.library in the stack trace but before that there's a lot of timer related stuff.

Imho timer and locate.library stuff will be always as some kind of "3d party junk", because timer usese all the times, and locale.libary uses a lot , and crashes with it happens very offten if just fill the "string" by trash.

Quote:

One version of OWB already works on this platform so it can't be OWB core itself. Then you say it can't be MUI because MUI version works already on another platform. But you guys have put a lot of effort to switch from MUI4 to MUI3 so you have a lot of different code.

Because changes in the core are different. Fab do that changes in core, joerg do (or not do at all) those changes in core. But yes, its can be anything, and mui as well.

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

@kas1e

Maybe you are on the state that you need some programmers who would like to help you by betatesting ?

Surely the last annoying bugs and/or freeze need the help from others peoples...

_________________
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

@Tomppeli

Quote:

One version of OWB already works on this platform so it can't be OWB core itself.

Of course it can be the core itself. It's not like it's the same webkit version at all.

Quote:

Then you say it can't be MUI because MUI version works already on another platform. But you guys have put a lot of effort to switch from MUI4 to MUI3 so you have a lot of different code.

It would still really need quite some motivation to crash an application in such an ugly way with just that MUI code. When browsing a page like it's done in these tests, there's not that much MUI code involved, except for actual drawing (which in turns is mostly bltbitmap/writepixelarray), event handling and refreshing titles here and there.

So my suspicion is definitely in WebKit platform dependant stuff rather than in the GUI itself. Unless some major mistake was made in the MUI code, of course. :)