@kas1e

Quote:

I think i also will try to compile everything without optimisation (now i use -O2), just in hope that crash info will be chacnged on something more readable.

I think optimisation must be used only when an application works correctly,
while debugging the optimisator can do nasty things and drive you on the wrong way.

@_Steve_

Quote:

_Steve_ wrote: @Framiga Let's try and keep the personal comments to PMs and not public. I don't see the need for them in this thread.

uncalled and redundant remark, as i already gave up with the thing

Thanks anyway for the suggestion

Last edited by Framiga on 28-Feb-2011 at 01:17 PM.

_________________

@kas1e

I don't know if this will help you or not, but since OWB version 1.9 and up, I also have problems on morphos 1.4.5 related to png.library. This didn't happen with version 1.8 or earlier. here is one part from the log, maybe FAB can see where the problem is.


LIB_FreePooled: Reached Large Puddle Area, your memblock can't be found anymore
LIB_FreePooled: Pool 0x216083a8, Memory 0x2547c768, Size 137
LIB_FreePooled: Pool Flags 0x1, Size 4096, Thresh 4096
LIB_FreePooled: Puddle 0x2182fefc, Type 0x0
-------------------------------------------------------------------
Alert: 0x0100000f
Alert: Process 0x2187e2e8
EmulHandle 0x218f7750
D0=00000089 00020000 0000000d 000000a8 000004e6 000002de 000000c0 000000ff
A0=216083a8 2547c768 253a8408 00000000 277fba08 2181b630 20000c44 218823c8
VBR=2000cf60 USP=218823c8 SSP=200028a8
PC=87654321 SR=0000 CCR=00 (X=0 N=0 Z=0 V=0 C=0)
SSP:
USP:
ShowPPCStackHistory: Stack 0x277fc060 StackEnd 0x277fd060
PPCStackFrame History:
ShowPPCStackHistory: StackPtr 0x277fc090
StackFrame[-0].LR-> Address 0x10117c74 **Not Valid**
ShowPPCStackHistory: StackPtr 0x277fc0c0
StackFrame[-1].LR-> Address 0x1010a87c **Not Valid**
ShowPPCStackHistory: StackPtr 0x277fc0e0
StackFrame[-2].LR-> Address 0x1010b148 **Not Valid**
ShowPPCStackHistory: StackPtr 0x277fc100
StackFrame[-3].LR-> Address 0x2128d844 -> MOSSYS:LIBS/png.library Hunk 1 Offset 0x0000043c
ShowPPCStackHistory: StackPtr 0x277fc110
StackFrame[-4].LR-> Address 0x2128f944 -> MOSSYS:LIBS/png.library Hunk 1 Offset 0x0000253c
ShowPPCStackHistory: StackPtr 0x277fc120
StackFrame[-5].LR-> Address 0x2128f908 -> MOSSYS:LIBS/png.library Hunk 1 Offset 0x00002500
ShowPPCStackHistory: StackPtr 0x277fc130
StackFrame[-6].LR-> Address 0x212933e8 -> MOSSYS:LIBS/png.library Hunk 1 Offset 0x00005fe0
ShowPPCStackHistory: StackPtr 0x277fc250
StackFrame[-7].LR-> Address 0x21293304 -> MOSSYS:LIBS/png.library Hunk 1 Offset 0x00005efc
ShowPPCStackHistory: StackPtr 0x277fc280
StackFrame[-8].LR-> Address 0x25e49174 -> OWB Hunk 1 Offset 0x008ac354
ShowPPCStackHistory: StackPtr 0x277fc2b0
StackFrame[-9].LR-> Address 0x25e49378 -> OWB Hunk 1 Offset 0x008ac558
ShowPPCStackHistory: StackPtr 0x277fc2d0
StackFrame[-10].LR-> Address 0x25b31a90 -> OWB Hunk 1 Offset 0x00594c70
ShowPPCStackHistory: MaxLevel end
Task 0x2187e2e8 Type 13 Pri 0
Flags 0x08 State 0x02 IDNestCnt -1 TDNestCnt -1
SigAlloc 0xffc0ffff SigWait 0x7c00d000 SigRecvd 0x00200020 SigExcept 0x00000000
ExceptCode 0x1010067c ExceptData 0x00000000 TrapCode 0x10100984 TrapData 0x00000000
Switch 0x00000000 Launch 0x00000000 UserData 0x00000000
SPReg 0x21882368 SPLower 0x2187e3cc SPUpper 0x218823cc
-------------------------------------------------------------------

_________________
Pegasos 2 G3 1 GB ram Radeon 9000 Pro MOS 1.4 sitting around collecting dust.

@Mo

Well, it's entirely unrelated, anyway. About your issue, noone else ever reported this before. I'd suggest double checking this png.library, and other system components as well (assuming you pasted the 1st hit and not the last, in which case it wouldn't be very useful). Also, you should mention how you actually trigger that hit.

Last edited by Fab on 28-Feb-2011 at 02:54 PM.

@Fab

Quote:

Well, it's entirely unrelated, anyway. About your issue, noone else ever reported this before. I'd suggest double checking this png.library, and other system components as well

png.library is ok, I have a very stable installation no hits or crashes, the only problem is OWB version 1.9 and above.

Quote:

Also, you should mention how you actually trigger that hit.

By starting OWB :)

_________________
Pegasos 2 G3 1 GB ram Radeon 9000 Pro MOS 1.4 sitting around collecting dust.

@Mo

Could be some corrupted png image somehow, then, if it happens right at start. Did you customize some of the images?

You could also try with morphos 2.x, by the way.

@Fab

don't bother yourself with me :) I don't use morphos for anything else than testing new stuff.

_________________
Pegasos 2 G3 1 GB ram Radeon 9000 Pro MOS 1.4 sitting around collecting dust.

@samo79

While i trying to test binary with "-g -O1" (500mb of size!) , can you do tests also with disabled image loading ? Just in case , maybe its still png library related somehow (because for example authors of png library, already ####s there and there, and for example with very latest png lib, we have DSIs on loading stage, while with some old one are ok). But just to be sure, tests withou images loading will be helpfull as well.

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

@kas1e

Ok, i try it

_________________
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

your signature link is dead.

@Beeblebrox

I know, one day i will solve this ...

_________________
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

@kas1e

Use -O0 (o zero) to get no optimization, not -O1.

_________________
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

@kas1e Quote:

For now it looks like something wrong with backporintg, which maybe related to timer, strings, locale or something in the OS / compiler itself.

With memory corruption, I don't think you can infer ANYTHING from what actually crashes. What I mean here is that you MIGHT be lead down entirely the wrong path.

But then again, I don't think you should be guessing anything (99.9% certain to never find the cause). Just disable as much code as possible (not OWB core, but any Amiga code, be it stuff called by OWB core, or MUI code, or whatever), unless you have a better method to locate the fault. However, I am beginning to sound like a broken record, so I refrain from saying anything else.

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

@ChrisH

Yeah, i think now i will start cut-off the parts one by one.

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

@kas1e

I was thinking... Is any code that runs in any of the subtasks in OWB using any exceptions (try/catch) anywhere??
This will absolutely not work at all and will cause this type of crash and lockup with our g++.

Try disabling all tasks and see what happens.

_________________
- 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

WebKit doesn't use exceptions.

@kas1e Quote:

Yeah, i think now i will start cut-off the parts one by one.

That will be a slow process. Best if you can disable "as much code as possible" in one go (i.e. at the most abstract level possible), then you can use a (human based!) binary search to find what part causes the problem. For example, maybe you can disable most of the GUI?

BTW, how ever much code you disable, for this method to work you NEED a (fairly) reliable way to reproduce the crash. Otherwise you will disable one bit of code, it seems to work (but in reality you were just lucky), so you partially enable some code, it crashes (this time you were unlucky), leading you to wrongly conclude that the faulty code was the code you just enabled. If this means you have to spend 30 mins each time you test OWB, then so be it, but really you will be much better if such test can be automated.

Last edited by ChrisH on 01-Mar-2011 at 11:27 AM.
Last edited by ChrisH on 01-Mar-2011 at 11:26 AM.

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

@kas1e

Regarding debugging mem trashes another thing I would do is to not always go on using the app until it finally freezes or crashes. The mungwall tool likely by default checks for mem trashes only when allocated memory is freed again. But if you are lucky there's an option to check all currently allocated memory for mem trashes. If so you should use that while the app is still (mostly) running fine. To see problems as early as possible.

If there's no such option in the mungwall tool, you should quit (and restart) app every once and then while it still is working fine but maybe showing some early hints about problem (gfx corruption or whatever) to force memory to be freeded and with it mem trash checks to be done.

@Fab

How about LibCURL or ICU ?

Can be one of these the real problem that can cause such freeze during navigation ?

_________________
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

CURL is written in C so it can't have exceptions, and ICU doesn't use exceptions either. And anyway, in your case, when favicons and network thread is disabled, there's only the main task where exceptions could possibly happen (timer task just pulses events with Signal(), nothing more).