Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
|
|
|
|
Poster | Thread | itix
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 11:24:29
| | [ #641 ] |
| |
 |
Elite Member  |
Joined: 22-Dec-2004 Posts: 3398
From: Freedom world | | |
|
| @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 |
| Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 12:35:42
| | [ #642 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | ChrisH
 |  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 12:40:33
| | [ #643 ] |
| |
 |
Elite Member  |
Joined: 30-Jan-2005 Posts: 6679
From: Unknown | | |
|
| @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... |
| Status: Offline |
| | ChrisH
 |  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 12:44:16
| | [ #644 ] |
| |
 |
Elite Member  |
Joined: 30-Jan-2005 Posts: 6679
From: Unknown | | |
|
| @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... |
| Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 12:52:42
| | [ #645 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | m3x
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 12:56:28
| | [ #646 ] |
| |
 |
Regular Member  |
Joined: 15-May-2003 Posts: 311
From: Bologna, Italy | | |
|
| @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 |
| Status: Offline |
| | Fab
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 13:11:25
| | [ #647 ] |
| |
 |
Super Member  |
Joined: 17-Mar-2004 Posts: 1178
From: Unknown | | |
|
| @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.
|
| Status: Offline |
| | samo79
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 13:25:13
| | [ #648 ] |
| |
 |
Elite Member  |
Joined: 13-Feb-2003 Posts: 3505
From: Italy, Perugia | | |
|
| @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 |
| Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 13:34:55
| | [ #649 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 13:35:56
| | [ #650 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | samo79
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 13:48:21
| | [ #651 ] |
| |
 |
Elite Member  |
Joined: 13-Feb-2003 Posts: 3505
From: Italy, Perugia | | |
|
| @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 webLast 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 |
| Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:01:37
| | [ #652 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:20:21
| | [ #653 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | nexus
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:22:03
| | [ #654 ] |
| |
 |
Regular Member  |
Joined: 11-Feb-2005 Posts: 430
From: Germany | | |
|
| @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! |
| Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:23:31
| | [ #655 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:28:36
| | [ #656 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | NutsAboutAmiga
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:29:02
| | [ #657 ] |
| |
 |
Elite Member  |
Joined: 9-Jun-2004 Posts: 12965
From: Norway | | |
|
| @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 |
| Status: Offline |
| | NutsAboutAmiga
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:31:03
| | [ #658 ] |
| |
 |
Elite Member  |
Joined: 9-Jun-2004 Posts: 12965
From: Norway | | |
|
| | Status: Offline |
| | kas1e
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:35:00
| | [ #659 ] |
| |
 |
Elite Member  |
Joined: 11-Jan-2004 Posts: 3551
From: Russia | | |
|
| @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 |
| Status: Offline |
| | NutsAboutAmiga
|  |
Re: AmigaOS4.1 OWB Development whilst we wait? Posted on 27-Feb-2011 14:42:22
| | [ #660 ] |
| |
 |
Elite Member  |
Joined: 9-Jun-2004 Posts: 12965
From: Norway | | |
|
| | Status: Offline |
| |
|
|
|
[ home ][ about us ][ privacy ]
[ forums ][ classifieds ]
[ links ][ news archive ]
[ link to us ][ user account ]
|