@ChrisH

Please note that Kas1e is using mungwall software on his OS4. It automatically fills allocated memory with a garbage unless MEMF_CLEAR was used in memory allocation.

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

@Cobra
Quote:

Does the same crash happen when you're not using memguard?

Yeah, same crashes without memguard.

@Itix
I do tests now without MemGuard, and that crashes which i have:

crash1 no_memguard
crash2 no_memguard
crash3 no_memguard
crash4 no_memguard

r12 even with memguard was not all the time DEADxxxx, and without memguard i almost never have any kind of DEADxxxx stuff. So, while i can easy disassemble OWB binary by IDA on winxp (the best disassembler for all the times, and fully understand even 68k hunks, as well as ELFs for many cpus), its still will make no sense, because r12 are random as well.

In the crash1 - there is some points to 68k code, but:

Quote:

[Deniil] I think this 68k stuff is just random [Deniil] the 68k disassembly is just irrelevant: [Deniil] 636F6CD8: FF28 linef [Deniil] 636F6CDA: 5EA5 addq.l #0x7,-(a5) [Deniil] 636F6CDC: FF2C linef [Deniil] 636F6CDE: 69BA bvs.b 0x636f6c9a [Deniil] 636F6CE0: FF33 linef [Deniil] linef is an exception. [Deniil] No normal code would look like this. [Deniil] I think it is rather PPC instructions than aren't used anymore (FF285EA5, FF2C69BA) and are in a segment it think is 68k code now...

In the crash2 , you can see some "stack trace", but its just again some kind of junk looks like. I disable totally that get_accepted_language function , and crashes are the same, and visually the same , and the crash-logs are the same (i do crash3 and crash4 after removing of that part on which point stacktrace in the part2). That part which we disable (which call get_languages_accepted) are in the some BAL file, and its called in every visiting of site. And code looks like this:

Quote:

#if OS(MORPHOS) char acceptedLanguages[256]; get_accepted_languages((char *) acceptedLanguages, sizeof(acceptedLanguages) - 1); #endif #if OS(MORPHOS) String headerString("Accept-Language"); headerString.append(": "); headerString.append(acceptedLanguages); headers = curl_slist_append(headers, headerString.latin1().data()); #endif

So that part are commented out for now, and still the same crash. But, in that part of commented code we again have somethig related to buffers, .data() and stuff. Still, removing of usage of get_accepted_languages() at all, not make any differences, and the same crashes still. Dunno if our crash have any connection to all that .data() stuff , because as fab say its internal in BAL and just should works (and is it , because Joerg for reaction-owb use the same BAL stuff).

But i have some kind of update : Almost for all the crashes (very offten), i have some kind of garbage-fancy-characters in the gauge at bottom of main window. Of course it imho have nothing with progress bar code itself , but its point me on the same memory trashing , as we have before with the filenames of the "download as / save as html / save as html".

And we fix it with fab like this:

Before was:
Quote:

char *name = (char *) decodeURLEscapeSequences(url.lastPathComponent()).latin1().data();

We add:
Quote:

char *name = strdup((char *) decodeURLEscapeSequences(url.lastPathComponent()).latin1().data()); + free(name) after usage

That fix memory trashing of file names, but dunno if its related to the same kind of memory trashing what we have for now or not, but:

1 . it works like this on morphos and works fine. We think that its because just our compiler code (glibc or kind) react different and sometime leave garbage, while it never leave garbage on morphos for some reassons.:

Quote:

[Fab1] dunno, but the .data() method of webcore string class is a bit particular [Fab1] basically, it's a temporary one, and when used twice, it can return crap. Never really understood why, but the point is it should be copied right away with strdup() (and freed later) [kas1e] did you notice ever on morphos that is return crap ? [Fab1] not in that case, no [kas1e] maybe different memory layouts, etc [kas1e] and just happens here by some reassons [kas1e] hm .. i start to think now - if it can cause random crashes for us ? [Fab1] i kinda doubt it

2. While trashing of gauge by fancy characters point me that its "the same kind of problem" i still dunno where exactly it can be, and how to found it. Crash so random , and happens just "After some time" , what mean, that OWB do something, do, alloc, free, dealoc , etc ,etc and by some reasson, somethere in the that OOP/C++ crap methods its start to trash memory, more , more , and then just when trashed memory is no more in some "bound", then just some random jump on crap => lockup.

Its just start to looks like some methods dealocates wrong, or allocates wrong, or kind of, and because of that C++/OOP ####, we have such strange crashlog.

In end, some chat log with deniil and fab (i hope they doesn't mind that i post it here), so maybe someone will have more ideas about :

Quote:

[Deniil] the .data() seems to return a string from the stack, like [Deniil] foo() { [Deniil] char str[10]; [Deniil] strcpy(str,"bar"); [Deniil] return str; [Deniil] } [Deniil] then str does not exist anymore when the function has returned, but if it is copied immediately it can still be used. [Deniil] Different compilers and OSes makes this behave differently. [Fab1] well, that would make no sense to have a method behaving like that, though [Deniil] well, it could be if it is documented that it has to be copied immediately [Fab1] i'm trying to look at the implementation, but it's a bit c++ hell to find it [Fab1] seems to be in BCCString.h [Fab1] which in turns returns data() from vector class [Fab1] const char* data() { return m_vector.data(); } [Fab1] in vector, that's T* data() { return m_buffer.buffer(); } [Fab1] seems all fine to me [Fab1] i don't quite get why .data() can get wrong, actually [kas1e2] the same as with char *name = (char *) decodeURLEscapeSequences(url.lastPathComponent()).latin1().data(); , or its different ? [Fab1] data is a cstring method [Fab1] latin1 is a String method that returns a CString object [Fab1] imo, it's related to refcount stuff in their mess :) [kas1e2] refcount ? [Fab1] some of their classes are reference counted [Fab1] deleted when reference count is 0 [kas1e2] it possible to delete/comment/replace or kind ? or it mess from mess ? [Fab1] well, relevant code is in BAL/Internationalization/WTF/Text/BCCString.cpp [Fab1] the others are inlined in the .h [Fab1] anyway, my biggest suspicion would be about m_buffer->hasOneRef() [Fab1] maybe refcount fails somehow in our cases [Fab1] which would skip the copy, and possibly return uninitialized memory [Fab1] but really, i don't know

We still have some thinks that maybe its about locale/strings at all .. but its all mess from the mess for now. Really dunno how we can catch that crapo-bug.

@CrhisH
I also of course thinking about disabling parts of code , but .. But its just so problematic, just because we can disable all the mui childs, and leave only one main window, + urlstring (or even just fastlinks only), but well - that mean, that still whole OWB are works, and we disable only MUI childs, which imho make there no sense.

Futher disabling , will mean disable something in OWB core, which, also make no sense because should works (just because Joerg as well use OWB core for the raction owb), of course , we have some changes in mui-owb in the core, but they are small, and related to timer task, webicon task and to some irrelevant (i hope) crap.

@all
What for me looks quite stable, its a look of the v0-v30 registers. And Fp30-31, almost always have some kind of "ascii kind stuff". Dunno if it mean anything of course or not ..

Last edited by kas1e on 27-Feb-2011 at 12:45 PM.
Last edited by kas1e on 27-Feb-2011 at 12:42 PM.
Last edited by kas1e on 27-Feb-2011 at 12:39 PM.

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

@itix Quote:

It automatically fills allocated memory with a garbage

But not UNallocated memory... (which may be what OWB is often accessing)

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@kas1e Quote:

that mean, that still whole OWB are works, and we disable only MUI childs, which imho make there no sense

Why no sense? Surely it is the MUI code that is (by all likelyhood) the cause of the problem?

Quote:

We still have some thinks that maybe its about locale/strings at all .. but its all mess from the mess for now. Really dunno how we can catch that crapo-bug.

When I run into this sort of memory trashing "phantom" bug, I found it NEVER worked to randomly guess where problem may lie. I had to methodically narrow down where the bug happens (perhaps using my suggested disable-code method).

Or to put it another way: There is no point giving the patient random "cures", in hope it might do something, when you don't even know the cause/illness. Chance of success very low.

Last edited by ChrisH on 27-Feb-2011 at 12:47 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH
Quote:

Why no sense? Surely it is the MUI code that is (by all likelyhood) the cause of the problem?

Well .. Dunno now what to think. We have also some changes in the main core , but small ones for sure. But maybe for first disabling of everything, and only keep fastlinks + rendering window can be a start to minimaze the mui code..

What make me madness now : why its just not show something "normal" in crash log. Why GR when tryes to spawn - crashes (when it should be memory protected and never crashes). Where is sense to have GR, if it can be ####ed as well as main programm ? Is there any other tools which can help us to found the problem, without disabling of code ?

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

@kas1e

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

_________________
Massimiliano Tretene, ACube Systems, Soft3

@ChrisH

Quote:

Why no sense? Surely it is the MUI code that is (by all likelyhood) the cause of the problem?

I would really not make this assumption. My guess is it's rather something deep in webkit/webcore, actually.

What's really annoying here is that serial debug is basically useless if it never shows any kind of stackframe (while GR does).

Last edited by Fab on 27-Feb-2011 at 01:12 PM.

@kas1e

Aniway, are you sure that all that lookups are "random" ?

Freezes happen on all website (and in any state of the application except the internal about page), just don't touch your machine for a certain period of time/minutes and then it freeze.

Not instantanely but only when you (for example) click on a link or try to digit a new URL.

(Of course it happen also using it)

OWB runs somethings in background even if you don't touch anithings ?
Try to check what OWB do in background, if it do somethings ...

Last edited by samo79 on 27-Feb-2011 at 01:26 PM.

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@samo79

Quote:

Aniway, are you sure that all that lookups are "random" ?

You as tester know its better :)

Quote:

Freezes happen on all website (and in any state of the application except the internal about page), just don't touch your machine for a certain period of time/minutes and then it freeze.

Just not touch at all, or touch after a while ? For me it never crashes if i just do nothing, but crasehes if i do nothing, and then, after a while, start to do something.

Quote:

Not instantanely but only when you (for example) click on a link or try to digit a new URL.

Well, what mean that when owb runs, its do something already, and memory start to trashes. But lockup happens only when you start to do something.

Quote:

OWB runs somethings in background even if you don't touch anithings ? Try to check what OWB do in background, if it do somethings ...

OWB do in backgorund Timer task , and muigfx.library task (as well as muimaster).

So, you jsut go at google.com , and then, after 30 minuts go to prefs and start to do something with it, will it lockups or not ? And will it always like this ? And will gauge at bottom have always those fancy characters at this point ?

Last edited by kas1e on 27-Feb-2011 at 01:36 PM.

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

@Fab
Quote:

I would really not make this assumption. My guess is it's rather something deep in webkit/webcore, actually.

But imho Joerg also use the same part of webkit/webcore for first versions of ra-owb ?

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

@kas1e

Quote:

Just not touch at all, or touch after a while ? For me it never crashes if i just do nothing, but crasehes if i do nothing, and then, after a while, start to do something.

Same here, for example ...

1 - Open: www.google.com
2 - Don't touch anythings and freeze youself on this page waiting 5 minutes
3 - Now digit somethings in google search and press enter

Gauge in statusbar start to progress but then if freeze on the middle or similar, then OWB is not responding anymore (Workbench will freezed too)

BTW: no text garbage in gauge, almost not always ...

Quote:

OWB do in backgorund Timer task , and muigfx.library task (as well as muimaster).

Well check them, maybe this damn Timer task ?

Quote:

So, you jsut go at google.com , and then, after 30 minuts go to prefs and start to do something with it, will it lockups or not ? And will it always like this ? And will gauge at bottom have always those fancy characters at this point ?

Nope, even after waiting i can open preferences, it start to freeze only when trying to browse the web

Last edited by samo79 on 27-Feb-2011 at 01:54 PM.
Last edited by samo79 on 27-Feb-2011 at 01:51 PM.
Last edited by samo79 on 27-Feb-2011 at 01:50 PM.

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@samo79

I do not know what can be with Timer task, which can cause such heavy memory trashing. Timer used for all the events in the whole OWB, so it should or works or not , but well .. of course if does not matter do you something or do nothing, and only after "some time" you have a crash when start to use it, then its somehow refer to timing .. Maybe timer just crashes by some reassons at some stage .. (that can explain, why for example when i have on backgorund digiclock or dopus , it first crash digiclock/dopusclock after owb freeze, and then workbench/input.device).

If mui prefs are works also, then it should be not mui code related as well. If you also can move mouse, and can works with prefs as long as you want, then it also not related to input events of mouse (and looks like not to input events at all).

Actuall crashing start to be when you trying to load anything , after long waiting then. And its can be again anything ..

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

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

@samo79
Quote:

Same here, for example ... 1 - Open: www.google.com 2 - Don't touch anythings and freeze youself on this page waiting 5 minutes 3 - Now digit somethings in google search and press enter

Do that , and no lockup. A even waiting 7 minuts, not 5. Then type 4-5 times something in google and type inter - all works.

Then i go here, and type that message. Still no lockup.

But after that i go to the amigans.net, read few posts, and then lockup (with exactly the same crash).

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

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

@kas1e

this is also only a very wild guess, but couldn't it be related to the caching (either memory or disk based) of web pages by OWB? It would explain, why the crash only occurs after a certain amount of time.

nexus

_________________
dye 'em black!

@nexus

Quote:

this is also only a very wild guess, but couldn't it be related to the caching (either memory or disk based) of web pages by OWB? It would explain, why the crash only occurs after a certain amount of time.

Possible as well (strange why then GR show such heavy crash, like some system components crashes, and not code).

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

@m3x
Quote:

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

You mean rename kernel.debug to kernel , and add to: /pci/ide/disk@0,0:0 amigaboot.of munge to have final line like that :

Quote:

/pci/ide/disk@0,0:0 amigaboot.of munge

?

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

@kas1e

If you can exclude components one by one until the crash stops.

If its some thing that stops working because of some pthreads / process or task, then its likely because of asynchronous behavior, put shampooers in there to stop one task from deleting a item while and other task read or writes to same item.

Its also likely the memory trashing comes from some memory being free before its being used, its so easy to make mistakes like that if your moving code around.

An other common mistake is allocate wrong amount of memory for structure.

For example.

Struct my_old;
{
int one;
};

Struct my_new
{
int one;
int two;
};

struct my_new var = AllocVec(MEMF_ANY, sizeof(struct my_old));

its so easy to forget to update all the sizeof()'s

then there is common mistake of not setting pointers to zero at the start of the code, resulting in any random cash.

After freeing memory or you should always set null to pointers, if pointer is reused afterwords you get zero pointer bug, and not memory corruption.

Last edited by NutsAboutAmiga on 27-Feb-2011 at 02:34 PM.
Last edited by NutsAboutAmiga on 27-Feb-2011 at 02:32 PM.
Last edited by NutsAboutAmiga on 27-Feb-2011 at 02:31 PM.
Last edited by NutsAboutAmiga on 27-Feb-2011 at 02:29 PM.

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

@kas1e

No edit sys:kickstart/ layout file.

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

@NutsAboutAmiga

Quote:

If you can exclude components one by one until the crash stops.

Its all not that easy like one function + another. Its hell of mess of C++ / C code, which use messing webkit (which are hell of C++) and its megabytes and megabytes of source codes.


Quote:

An other common mistake is allocate wrong amount of memory for structure.

That all fine, but the code already works on morphos fine. If fab forget something like this somethere, morphos should have the same problems. For now it looks like something wrong with backporintg, which maybe related to timer, strings, locale or something in the OS / compiler itself.

Quote:

No edit sys:kickstart/ layout file.

So then just change
Quote:

MODULE Kickstart/kernel on the

on

Quote:

MODULE Kickstart/kernel.debug munge

?

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

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

@kas1e

Yes some thing like that. (keep you boot cd close)

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