Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
60 user(s) are online (40 user(s) are browsing Forums)

Members: 3
Guests: 57

emeck, jarokuczi, thellier, more...

Support us!

Headlines

 
  Register To Post  

« 1 ... 16 17 18 (19) 20 21 22 ... 72 »
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
Do search for all FindTaks in all the code everywhere, and there is all files which contain it (not many):

http://kas1e.mikendezign.com/temp/findtask/
Way too much nonsense for even trying to fix it (using malloc() instead of exec memory allocation functions with MEMF_SHARED to allocate structures which are passed to OS functions like IDOS->StartNotify(), trying to mess around with parts of the undocumented tc_ETask which don't exist, trying to send Arexx messages to an "AMBIENT" port, etc.).

If it's something in these parts and not NP_StartMsg != NP_NotifyOnDeathMessage it might be using tc_UserData for 2 different things: In BCThreadSpecificWTF.cpp for a pointer to a MinList and, only on AmigaOS but not on MorphOS, in BCThreadingMorphOS.cpp and BCThreadingWTF.cpp for a NewThreadContext pointer.

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Quote:

Maybe you will find something if you have some time


these may or may not be critical but I see the following:


In main.cpp you roll your own struct NoifyRequest. That should be allocated with AllocDosObject() since version 51.

In splashwindclass.cpp you set pr_WindowPtr explicitly, you should use IDOS->SetProcWindow() since version 50.

Same again in downloadlistclass.cpp


Otherwise I couldn't see any bad other process access etc. The code uses tc_UserData a lot and never seems to save the original value (which is fine for tasks you spawn) if that happened to the main process it might cause bad affect, but I didn't see anywhere where that happened

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@broadblues

Quote:
these may or may not be critical but I see the following:

In main.cpp you roll your own struct NoifyRequest. That should be allocated with AllocDosObject() since version 51.
This one is, even if not for his current crashes (unless he has too few RAM). You must not pass MEMF_PRIVATE memory to OS functions and the C library functions like malloc() of course use unlocked MEMF_PRIVATE memory.

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

A quick request, I know, it's too early for requests...

In MIME Types can the behaviour of %f be changed, at the moment it ignores anything else in the gadget. Can the be changed to embed the temp filename into the gadget contents.

For example %f.m3u would create a file called OWB_TempFile_1393543241.m3u

which would enable amigaamp3 to work with a simple external viewer call of "appdir:amigaamp3 %f.m3u" instead of the dos script I have to use now to use wget to download the m3u file and run amigaamp3.

Amiga user since 1985
AOS4, A-EON, IBrowse & Alinea Betatester

Ps. I hate the new amigans website. <shudder>
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@joerg,andy

Quote:

In main.cpp


All that dos_notify stuff in no use and commented out (see at end of the main.cpp commented dosnotify_init(); and dosnotify_cleanup(); as well as dosnotify_start() in use only in bookmarkgroupclass.cpp, where it also commented out.

I just dind't remove it from code, as it change nothing as functions didn't called at all anywhere.

@Joerg
Quote:

trying to mess around with parts of the undocumented tc_ETask which don't exist


MachineStackMarker.cpp wasn't touched at all and its something which appears to be since 1.16 and need fixes, yes. Maybe you can help with ?

Through, while it can be related to some crashes in JS, 1.16 (with that untouched file) , didn't crashes on second run from shell like it do with 1.23 now.

Quote:

trying to send Arexx messages to an "AMBIENT" port


That to be fixed too: for download manager now def_icons will be shown (i.e. if you download .lha file, you will have image of .lha file) : on mos its done for ambient, for us it need to be replaced for deficons or whatever. That to be done, but currently cause no harm, and we just have simple plain image for all downloaded files currently. But that to be fixed of course, just after that sucking process trashing.


@joerg
Quote:

it might be using tc_UserData for 2 different things: In BCThreadSpecificWTF.cpp for a pointer to a MinList and, only on AmigaOS but not on MorphOS, in BCThreadingMorphOS.cpp and BCThreadingWTF.cpp for a NewThreadContext pointer.


Have any better idea ?:) Anyway, as Fab says "Probably your threading backend has an issue with the startup/end message handling.", then it still can be that NP_StartupMsg/NP_NotifyDeathMessage, but we found nothing better but to do it like this. If you have other ideas, will be nice to try them out as well.

In morphos SDK i found:

from exec.doc:
Quote:

TASKINFOTYPE_STARTUPMSG

returns pointer to struct Message passed in with NP_StartupMsg or ASKTAG_STARTUPMSG, NULL if no startup message was specified, at the DataPtr address if the DataSize is large enough. This message is ReplyMsg()'d by the system when task/process exit. Size = sizeof(struct Message*)


from dos/dostags.h:
Quote:

#define NP_StartupMsg (NP_Dummy + 28) /* struct Message *, ReplyMsg'd at exit */


And there is example from their SDK "procmessages.c - Example program for the NP_StartupMsg and NP_TaskMsgPort features":

http://kas1e.mikendezign.com/temp/threading/procmessages.c

Checking also 2-3 years ago old logs about and:

Quote:

q: what's NP_StartupMsg?

a: a message that is replied at end of task
a: it's used for thread synchronization, in this case (waiting for thread end)
a: message is used to wait for end of child the goal is to implement webkit thread api

q: end, not startup?

a: and join() waits for child
a: BCThreadingMorphOS.cpp -> waitForThreadCompletion()

q: so then we could use NP_NotifyOnDeathMessage on OS4

a: you use anything you want, as long as you can make it behave the same

-----

q: what is TASKINFOTYPE_STARTUPMSG btw ?
a: a tag to retrieve the startup message passed at task/process creation
q: mos specific ?
a: yes




@Andy
Quote:

In splashwindclass.cpp and downloadlistclass.cpp


Splashwindow used for splashwindow when fontconfig generation progress window starts , and when cache file is done, it didn't starts , so can't be our problems with trashing of process. Same for donwloadlistclass: its only in use when we do downloading, so also can't be. As for reproduce crash i enough just run and exit and run again.

@Severin
If it something which happens on morphos also, then its better to send req for Fab


Edited by kas1e on 2014/2/28 5:37:21
Edited by kas1e on 2014/2/28 5:42:29
Edited by kas1e on 2014/2/28 5:48:28
Edited by kas1e on 2014/2/28 5:55:58
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
@joerg
Quote:
it might be using tc_UserData for 2 different things: In BCThreadSpecificWTF.cpp for a pointer to a MinList and, only on AmigaOS but not on MorphOS, in BCThreadingMorphOS.cpp and BCThreadingWTF.cpp for a NewThreadContext pointer.

Have any better idea ?:)

BCThreadingMorphOS.cpp: Replace NP_UserData,(ULONG) data by NP_EntryData, (uint32)data
BCThreadingWTF.cpp:
static void threadEntryPoint(void* contextData)
{
#ifdef __amigaos4__
NewThreadContext* context = reinterpret_cast NewThreadContext* (IDOS->GetEntryData());
#else


Quote:
it still can be that NP_StartupMsg/NP_NotifyDeathMessage, but we found nothing better but to do it like this. If you have other ideas, will be nice to try them out as well.
It seems it can be used, the MorphOS name just makes no sense, according to what you quoted it's more like a NP_EndMsg.
But not that way on AmigaOS, check the dos.library autodoc: The argument of NP_NotifyOnDeathMessage has to be a struct DeathMessage!
You have to use
#ifdef __amigaos__
struct ThreadStartMsg
{
struct DeathMessage tsm_Msg;
void* tsm_Result;
};
#else
struct ThreadStartMsg
{
struct Message tsm_Msg;
void* tsm_Result;
};
#endif
and fix all code using ThreadStartMsg, don't use malloc() but IExec->AllocVecTags(sizeof(struct ThreadStartMsg), AVT_Type, MEMF_SHARED, TAG_DONE) to allocate it, IExec->FreeVec() to free it, etc.


Edited by joerg on 2014/2/28 8:29:06
Edited by joerg on 2014/2/28 8:32:31
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@joerg
Start replacing, and in BCThredingMorphOS.cpp there is still those parts to deal with :

startup_msg->tsm_Msg.nm_Node.ln_Type = NT_MESSAGE;
startup_msg->tsm_Msg.mn_ReplyPort = threadHandle->td_MsgPort;
startup_msg->tsm_Msg.nm_Length = sizeof (*startup_msg);

For which we have:

struct DeathMessage has no member named mn_Node, nm_ReplyPort and mn_Lenght.

checked structs of deathmessage and message and they sure different. Commented those parts out will not help as well, as in the waitForThreadCompletion() it's all in use


Edited by kas1e on 2014/2/28 9:07:24
Edited by kas1e on 2014/2/28 9:13:06
Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e
Maybe I'm wrong, but OS4.1 SDK headers are:
<pre>...
struct DeathMessage
{
struct Message dm_Msg; /* Embedded exec message structure. */
int32 dm_ReturnCode; /* Primary process return code, set by DOS */
int32 dm_Result2; /* The value returned from IoErr(),set by DOS */
};
...</pre>
And as it has/points to struct Message:
<pre>/****** Message *****************************************************/

struct Message
{
struct Node mn_Node;
struct MsgPort * mn_ReplyPort; /* message reply port */
uint16 mn_Length; /* total message length, in bytes,
(include the size of the Message
structure in the length) */
};

/****************************************************************************/</pre>
It could be something like:
startup_msg->tsm_Msg.<b>dm_Msg.</b>nm_Node.ln_Type = NT_MESSAGE;

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@jabirulo
Yep indeed

@joerg
Done (still working on replacing mallocs), there is new files:

http://kas1e.mikendezign.com/temp/joerg/


But still crash the same. I even enable debug in all that threading files, and that what we have when we run/exit from and then run it again:

initializeThreading()
establishIdentifierForThreadHandle() adding thread id 1
mainThreadIdentifier 1
isMainThread
() 1
ThreadCondition
::ThreadCondition()
ThreadCondition::ThreadCondition() OK
createThreadInternal
([OWBIconDatabase)
syncPortByProcess(0x65E6A1E0)
createSyncPortForThreadProcess(0x65E6A1E0) -> MsgPort 0x64E17650
createReplyState
(0x64ECDD780x64ECDE18) -> 0x64ECDE40
establishIdentifierForThreadHandle
() adding thread id 2
setThreadNameInternal
([OWBIconDatabase)
ThreadCondition::wait()
ThreadCondition::signal()
ThreadCondition::signal() OK
ThreadCondition
::wait() OK
ThreadCondition
::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::ThreadCondition()
ThreadCondition::ThreadCondition() OK
createThreadInternal
([OWBJavaScriptCore::BlockFree)
syncPortByProcess(0x65E6A1E0)
createReplyState(0x64F297B00x64E86EC0) -> 0x64F297C8
establishIdentifierForThreadHandle
() adding thread id 3
ThreadCondisetThreadNameInternal
([OWBJavaScriptCore:tion::ThreadCondition()
Thre:BlockFree)
ThreadCondition::timedWait()
adCondition::ThreadCondition() OK
ThreadCondition
::ThreadCondition()
ThreadCondition::ThreadCondition() OK
ThreadCondition
::ThreadCondition()
ThreadCondition::ThreadCondition() OK
ThreadCondition
::ThreadCondition()
ThreadCondition::ThreadCondition() OK
ThreadCondition
::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::signal()
ThreadCondition::broadcast()
ThreadCondition::broadcast()
ThreadCondition::broadcast()
ThreadCondition::signal()
ThreadCondition::signal() OK
ThreadCondition
::timedWait() caught signal1
ThreadCondition
::timedWait()
ThreadCondition::wait()
ThreadCondition::timedWait() caught signal0
ThreadCondition
::timedWait()
ThreadCondition::timedWait() caught signal0
ThreadCondition
::wait()
ThreadCondition::signal()
ThreadCondition::signal() OK
waitForThreadCompletion
(2) -> threadHandle 0x64ECDD78
threadReplyStatThreadCondition
::wait() OK
eByThreadHandle
(0x64ECDD78)
Matching threadreplystate 0x64ECDE40
Waiting 
for startupmsg
threadReplyStateByThreadStartMsg
(0x64ECDE18)
Our threadproceed
removeThreadReplyState
(0x64ECDE40)
pendingChildrenForThread(0x65E6A1E0)
Remaining children 1
waitForThreadCompletion
(2OK
ThreadCondition
::broadcast()
waitFoThreadCondition::wait() OK
rThreadCompletion
(3) -> threadHandle 0x64F297B0
threadReplyStateByThreadHandle
(0x64F297B0)
Matching threadreplystate 0x64F297C8
Waiting 
for startupmsg
threadReplyStateByThreadStartMsg
(0x64E86EC0)
Our threadproceed
removeThreadReplyState
(0x64F297C8)
pendingChildrenForThread(0x65E6A1E0)
Remaining children 0
removeSyncPort
(0x64E17650)
DeleteMsgPort(0x64E17650)
waitForThreadCompletion(3OK

<< now we just run again from shell >>

initializeThreading()
Dump of context at 0xEFD837C0
Trap type
DSI exception
Machine State 
(raw): 0x0200F030
Machine State 
(verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
Instruction pointerin module kernel+0x0002009C (0x0182009C)
Crashed processowb (0x65E6A1E0)
DSI verbose error descriptionAccess not found in hash or BAT (page fault)
Access was a load operation
 0
65351FC4 65550940 ABADCAFE 65351FC0 659C8600 659C8600 64597040 659C8610
 8
000000E3 020C2BEC 64E763F0 021D69A6 00000154 6577FB80 00000000 65FDE380
16
7D4E70B4 00000000 68241090 65550C08 02290000 02290000 00000000 00000001
24
64E18880 64E18880 00000000 020A0000 7ECB41AC 659C8600 65351FC0 020C2BEC
CR
35953A95   XERA000CA7E  CTR: 018200B0  LR: 0182012C
DSISR
40000000  DAR65351FC8

FP0 
FFF8000082024000 3FF0000000000000 3FEFFFEB000DC7F7 41D4C43F73870853
FP4 
0000000000000000 4048E66660000000 405FF33340000000 41E0000000000000
FP8 
0000000000000000 BF60182436517A27 3ED0306CD997DDE4 BF701ACDBB94A830
FP12
3FF0000000000000 4052000000000000 0000000000000000 0000000000000000
FP16
0000000000000000 0000000000000000 0000000000000000 0000000000000000
FP20
0000000000000000 0000000000000000 0000000000000000 0000000000000000
FP24
0000000000000000 0000000000000000 0000000000000000 0000000000000000
FP28
0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR
82024000

V0 
00000000000000000000000000000000 00000000000000000000000000000000
V2 
FE0113ECFE0124DBFE013FC0FE013FC0 FE0113ECFE0124DBFE013FC0FE013FC0
V4 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 01000100010001000100010001000100
V6 
00000000000000000000000000000000 00000000000000000000000000000000
V8 
00000000000000000000000000000000 00000000000000000000000000000000
V10
01010101010101010101010101010101 00000000000000000000000000000000
V12
00000000000000000000000000000000 00000000000000000000000000000000
V14
: 001002120414061608180A1A0C1C0E1E 01000100010001000100010001000100
V16
FF000000FF000000FF000000FF000000 FF49140FFF8B251CFFEE4030FFEE4030
V18
00000000000000000000000000000000 00000000000000000000000000000000
V20
00000000000000000000000000000000 00000000000000000000000000000000
V22
00000000000000000000000000000000 00000000000000000000000000000000
V24
00000000000000000000000000000000 00000000000000000000000000000000
V26
00000000000000000000000000000000 00000000000000000000000000000000
V28
00000000000000000000000000000000 00000000000000000000000000000000
V30
00000000000000000000000000000000 00000000000000000000000000000000
VSCR
00000000 VRSAVE00000000

Kernel command line
serial munge

Registers pointing to code
:
r9 native kernel module kernel+0x008c2bec
r11
native kernel module kernel+0x009d69a6
r13
_ZN7WebCoreL12ab_blackListE()+0x0 (section 22 0x551C)
r16main()+0x0 (section 1 0x1090)
r23module owb at 0x00000001 (section 0 0xFFFFFFDC)
r27native kernel module kernel+0x008a0000
r28
_ZN3WTF23threadSpecificKeyCreateEPPNS_18ThreadSpecificNodeEPFvPvE()+0xac (section 1 0x17CE188)
r31native kernel module kernel+0x008c2bec
ip 
native kernel module kernel+0x0002009c
lr 
native kernel module kernel+0x0002012c
ctr
native kernel module kernel+0x000200b0

Stack trace
:
(
0x65550940native kernel module kernel+0x0002009c
(0x65550970native kernel module kernel+0x0002012c
(0x65550990_ZN3WTF19initializeThreadingEv()+0x3e4 (section 1 0x17A906C)
(
0x65550A10_ZN3JSC19initializeThreadingEv()+0x64 (section 1 0x1509FC8)
(
0x65550A20_ZL12handleOM_NEWP6IClassPmP5opSet()+0x134 (section 1 0x966C)
(
0x65550AE0_ZL8dispatchP6IClassPmP4_Msg()+0x438 (section 1 0xF5C8)
(
0x65550B20native kernel module intuition.library.kmod+0x0001824c
(0x65550B80native kernel module intuition.library.kmod+0x00018470
(0x65550C00native kernel module intuition.library.kmod+0x0000839c
(0x65550C30native kernel module intuition.library.kmod+0x00008130
(0x65550CA0_Z18create_applicationPc()+0xd4 (section 1 0x878)
(
0x65550CD0main()+0x144 (section 1 0x11D4)
(
0x65550D00native kernel module newlib.library.kmod+0x000020a4
(0x65550D70native kernel module newlib.library.kmod+0x00002d0c
(0x65550F10native kernel module newlib.library.kmod+0x00002ee8
(0x65550F50_start()+0x170 (section 1 0x16C)
(
0x65550F90native kernel module dos.library.kmod+0x00025208
(0x65550FC0native kernel module kernel+0x0006acdc
(0x65550FD0native kernel module kernel+0x0006ad5c

Disassembly of crash site
:
 0182008
C7FE00008   trap
 
01820090: 4BFFFEB4   b                 0x181FF44
 
01820094: 38030004   addi              r0,r3,4
 
01820098: 90040000   stw               r0,0(r4)
>0182009
C81230008   lwz               r9,8(r3)
 018200
A090890000   stw               r4,0(r9)
 018200
A491240004   stw               r9,4(r4)
 018200
A890830008   stw               r4,8(r3)
 018200
AC4E800020   blr
 
018200B07C0802A6   mflr              r0
Stack pointer 
(0x65550940is inside bounds
Redzone is OK 
(4)




Edited by kas1e on 2014/2/28 10:08:22
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Maybe not directly related to the crash, but in the crashlog you have 0xABADCAFE in register r2. That's the value used for filling memory allocated with IExec->Alloc[Mem|Vec|VecTags](), something is accessing allocated memory which wasn't initialized yet.
IIRC r2 is used on MorphOS for something MorphOS specific which doesn't exist on AmigaOS, make sure r2 isn't accessed anywhere in the MorphOS code you are using.

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:
@Severin
If it something which happens on morphos also, then its better to send req for Fab


As I don't have morphos that would be rather difficult to check.

Btw. there's at least one call to MOSSYS: in the printing routines, opening printer prefs I assume.

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@Severin
Quote:

Btw. there's at least one call to MOSSYS: in the printing routines, opening printer prefs I assume.


That why i don't want to give any beta to anyone because i know there will be report of such kind : it fixed in 1.16, but in times when you ask for beta for show it wasn't in 1.23 (trivial change, but beta is beta). Do all tests on 1.16 plz.

@Joerg
Quote:

Maybe not directly related to the crash, but in the crashlog you have 0xABADCAFE in register r2. That's the value used for filling memory allocated with IExec->Alloc[Mem|Vec|VecTags](), something is accessing allocated memory which wasn't initialized yet.
IIRC r2 is used on MorphOS for something MorphOS specific which doesn't exist on AmigaOS, make sure r2 isn't accessed anywhere in the MorphOS code you are using.


What is strange is that its different all the time (i mean values in registers). Now it show abadcafe, another time its all random, another time even meet with deadbeef. Sometimes DAR are 0x0000000 , some times some "fine" value.

I think i need to put debug prinfs in the void initializeThreading() after each call, just because it crashes on second run after initializeThreading() prinfs, but didn't print "establishIdentifierForThreadHandle() adding thread id 1", so something between. Maybe from that somehow can understand wtf happens.

Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@kas1e

The problem may be that for whatever reason there is some context information (from things like threading lib, clib) connected to the Shell task that (partly) "survives" the "exit/restart program" process and gets re-used when you start the program the second time but shouldn't be re-used.

If it is known (unlikely?) where such context information is stored exactly you could try to NULL it out very early during program start as a test.


Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
Yep, have crash if i just run odyssey, then close, and then run joerg's owb for example. Crashlog:
I don't understand why you don't debug your own executables, but this crash in OWB 3.32 is an intentional crash (accessing 0 in an internal exception handler used for example for debugging deadlocks) and therefore useless to find your bugs in Odyssey. Except that Odyssey returns with the SIGBREAKF_CTRL_E signal set, which it shouldn't do.

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@all
Just enable more debug, and so, when i first run it :

initializeThreading()
we in initializeThreading(): inside of the !atomicallyinitializedstaticmutex and before StringImp::empty
we in initializeThreading(): before atoicallyinitializedstaticmutex = new Mutex
we in initializeThreading
(): before threadmapmutex()
we in initializeThreading(): before syncportmapmutex()
we in initializeThreading(): before threadReplyStateMapMutex()
we in initializeThreading(): before wtfThreadData()
we in initializeThreading(): before initializeRandomNumberGenerator()
we in initializeThreading(): before s_dtoap5mutex = new mutex
we in initializeThreading
(): before initializeDates
we in initializeThreading
(): before mainthreadidentifier currentThread()
establishIdentifierForThreadHandle() adding thread id 1
mainThreadIdentifier 1
isMainThread
() 1
ThreadCondition
::ThreadCondition()
ThreadCondition::ThreadCondition() OK
createThreadInternal
([OWBIconDatabase)

..
blblabla...


After that i exit, threads cleans, etc, and do run second time , and have:

initializeThreading()
we in initializeThreading(): inside of the !atomicallyinitializedstaticmutex and before StringImp::empty
we in initializeThreading(): before atoicallyinitializedstaticmutex = new Mutex
we in initializeThreading
(): before threadmapmutex()
we in initializeThreading(): before syncportmapmutex()
we in initializeThreading(): before threadReplyStateMapMutex()
we in initializeThreading(): before wtfThreadData()
Dump of context at 0xEFD8DBA0
Trap type
DSI exception
Machine State 
(raw): 0x0200F030
Machine State 
(verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
Instruction pointerin module kernel+0x0002009C (0x0182009C)
Crashed processowb (0x65EC19F0)
DSI verbose error descriptionAccess not found in hash or BAT (page fault)
Access was a load operation
 0
65349FC4 65548940 DEADBEEF 65349FC0 65978600 65978600 63EA9040 65978610
 8
000000E3 020C2BEC 651A43F0 021D69A6 00000154 65777BA8 00000000 69149040
16
7D4E70B4 00000000 66D05420 65548C08 02290000 02290000 00000000 00000001
24
659F5DD0 659F5DD0 00000000 020A0000 7ECB43B0 65978600 65349FC0 020C2BEC
CR
35953E95   XERE000BE6F  CTR: 018200B0  LR: 0182012C
DSISR
40000000  DAR65349FC8


FP0 
FFF8000082024000 3FF0000000000000 3FEFFFEB000DC7F7 41D4C43F73870853
FP4 
0000000000000000 4048E66660000000 405FF33340000000 41E0000000000000
FP8 
0000000000000000 BF60182436517A27 3ED0306CD997DDE4 BF701ACDBB94A830
FP12
3FF0000000000000 4052000000000000 0000000000000000 0000000000000000
FP16
0000000000000000 0000000000000000 0000000000000000 0000000000000000
FP20
0000000000000000 0000000000000000 0000000000000000 0000000000000000
FP24
0000000000000000 0000000000000000 0000000000000000 0000000000000000
FP28
0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR
82024000

V0 
00000000000000000000000000000000 00000000000000000000000000000000
V2 
FE0113ECFE0124DBFE013FC0FE013FC0 FE0113ECFE0124DBFE013FC0FE013FC0
V4 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 01000100010001000100010001000100
V6 
00000000000000000000000000000000 00000000000000000000000000000000
V8 
00000000000000000000000000000000 00000000000000000000000000000000
V10
01010101010101010101010101010101 00000000000000000000000000000000
V12
00000000000000000000000000000000 00000000000000000000000000000000
V14
: 001002120414061608180A1A0C1C0E1E 01000100010001000100010001000100
V16
FF000000FF000000FF000000FF000000 FF49140FFF8B251CFFEE4030FFEE4030
V18
00000000000000000000000000000000 00000000000000000000000000000000
V20
00000000000000000000000000000000 00000000000000000000000000000000
V22
00000000000000000000000000000000 00000000000000000000000000000000
V24
00000000000000000000000000000000 00000000000000000000000000000000
V26
00000000000000000000000000000000 00000000000000000000000000000000
V28
00000000000000000000000000000000 00000000000000000000000000000000
V30
00000000000000000000000000000000 00000000000000000000000000000000
VSCR
00000000 VRSAVE00000000

Kernel command line
serial munge

Registers pointing to code
:
r9 native kernel module kernel+0x008c2bec
r11
native kernel module kernel+0x009d69a6
r13
_ZZNK7WebCore27TimelineTraceEventProcessor10TraceEvent9parameterEPKcNS0_15TraceValueTypesEE12missingValue()+0x0 (section 22 0x5504)
r16main()+0x0 (section 1 0x1090)
r23module owb at 0x00000001 (section 0 0xFFFFFFDC)
r27native kernel module kernel+0x008a0000
r28
_ZN3WTF23threadSpecificKeyCreateEPPNS_18ThreadSpecificNodeEPFvPvE()+0xac (section 1 0x17CE38C)
r31native kernel module kernel+0x008c2bec
ip 
native kernel module kernel+0x0002009c
lr 
native kernel module kernel+0x0002012c
ctr
native kernel module kernel+0x000200b0

Stack trace
:
(
0x65548940native kernel module kernel+0x0002009c
(0x65548970native kernel module kernel+0x0002012c
(0x65548990_ZN3WTF19initializeThreadingEv()+0x5e8 (section 1 0x17A9270)
(
0x65548A10_ZN3JSC19initializeThreadingEv()+0x64 (section 1 0x1509FC8)
(
0x65548A20_ZL12handleOM_NEWP6IClassPmP5opSet()+0x134 (section 1 0x966C)
(
0x65548AE0_ZL8dispatchP6IClassPmP4_Msg()+0x438 (section 1 0xF5C8)
(
0x65548B20native kernel module intuition.library.kmod+0x0001824c
(0x65548B80native kernel module intuition.library.kmod+0x00018470
(0x65548C00native kernel module intuition.library.kmod+0x0000839c
(0x65548C30native kernel module intuition.library.kmod+0x00008130
(0x65548CA0_Z18create_applicationPc()+0xd4 (section 1 0x878)
(
0x65548CD0main()+0x144 (section 1 0x11D4)
(
0x65548D00native kernel module newlib.library.kmod+0x000020a4
(0x65548D70native kernel module newlib.library.kmod+0x00002d0c
(0x65548F10native kernel module newlib.library.kmod+0x00002ee8
(0x65548F50_start()+0x170 (section 1 0x16C)
(
0x65548F90native kernel module dos.library.kmod+0x00025208
(0x65548FC0native kernel module kernel+0x0006acdc
(0x65548FD0native kernel module kernel+0x0006ad5c

Disassembly of crash site
:
 0182008
C7FE00008   trap
 
01820090: 4BFFFEB4   b                 0x181FF44
 
01820094: 38030004   addi              r0,r3,4
 
01820098: 90040000   stw               r0,0(r4)
>0182009
C81230008   lwz               r9,8(r3)
 018200
A090890000   stw               r4,0(r9)
 018200
A491240004   stw               r9,4(r4)
 018200
A890830008   stw               r4,8(r3)
 018200
AC4E800020   blr
 
018200B07C0802A6   mflr              r0
Stack pointer 
(0x65548940is inside bounds
Redzone is OK 
(4)


So on wtfThreadData(); , which is here:
http://kas1e.mikendezign.com/temp/threading/BCWTFThreadDataWTF.cpp

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@Georg

It could be anything, something in struct Process overwritten, or in struct CommandLineInterface, dos.library Input()/Output() files replaced by Odyssey but not restored on exit, ...
As long as Roman doesn't build his executables with debugging information (-gstabs) and checks where exactly it crashes and what it's doing there on the 2nd run it's impossible to find out what it is.

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Quote:If USE(WEB_THREAD) is enabled you are mixing MorphOS threading with pthreads threading: if (pthread_main_np() ...).
And the wtfThreadData() function isn't there, it's probably in the include file.

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@joerg
Quote:

If USE(WEB_THREAD) is enabled you are mixing MorphOS threading with pthreads threading: if (pthread_main_np() ...).


Added prinfs to:

Quote:

#if USE(WEB_THREAD)

D(kprintf("BCWTFThreadDataWTF.cpp: we are in WEB_THREAD");

static JSC::IdentifierTable* sharedIdentifierTable = new JSC::IdentifierTable();
if (pthread_main_np() || isWebThread())
m_defaultIdentifierTable = sharedIdentifierTable;
else
m_defaultIdentifierTable = new JSC::IdentifierTable();

m_currentIdentifierTable = m_defaultIdentifierTable;
#endif


Result is that nope, we not in (at least when i run/exit/run, i didn't found that printf on serial).

Quote:

And the wtfThreadData() function isn't there, it's probably in the include file.


include file: http://kas1e.mikendezign.com/temp/threading/BCWTFThreadDataWTF.h


Also enabled -gstabs for BCThreadingMorphOS object, and crash on second run happens later than before by prinfs, i.e.:

Quote:

initializeThreading()
we in initializeThreading(): inside of the !atomicallyinitializedstaticmutex and before StringImp::empty
we in initializeThreading(): before atoicallyinitializedstaticmutex = new Mutex
we in initializeThreading(): before threadmapmutex()
we in initializeThreading(): before syncportmapmutex()
we in initializeThreading(): before threadReplyStateMapMutex()
we in initializeThreading(): before wtfThreadData()
we in initializeThreading(): before initializeRandomNumberGenerator()
we in initializeThreading(): before s_dtoap5mutex = new mutex
we in initializeThreading(): before initializeDates
we in initializeThreading(): before mainthreadidentifier = currentThread()


<<CRASH>>


stack trace on second run when that crash happens with -gstabs on that object looks like this:

Stack trace:
(
0x648C58D0native kernel module kernel+0x000200a0
(0x648C5900native kernel module kernel+0x0002012c
(0x648C5930) [/usr/local/amiga/odyssey-r155188-1.23/BAL/Types/WTF/MorphOS/BCThreadingMorphOS.cpp:806_ZN3WTF5Mutex4lockEv()+0x3c (section 1 0x17A6F2C)
(
0x648C5940) [/usr/local/amiga/odyssey-r155188-1.23/BAL/Types/WTF/MorphOS/BCThreadingMorphOS.cpp:55_ZN3WTFL18identifierByThreadEPv()+0x88 (section 1 0x17A7FA8)
(
0x648C5970) [/usr/local/amiga/odyssey-r155188-1.23/BAL/Types/WTF/MorphOS/BCThreadingMorphOS.cpp:714_ZN3WTF13currentThreadEv()+0x74 (section 1 0x17A8B78)
(
0x648C5990) [/usr/local/amiga/odyssey-r155188-1.23/BAL/Types/WTF/MorphOS/BCThreadingMorphOS.cpp:214_ZN3WTF19initializeThreadingEv()+0x3c4 (section 1 0x17A906C)
(
0x648C5A10_ZN3JSC19initializeThreadingEv()+0x64 (section 1 0x1509FC8)
(
0x648C5A20_ZL12handleOM_NEWP6IClassPmP5opSet()+0x134 (section 1 0x966C)
(
0x648C5AE0_ZL8dispatchP6IClassPmP4_Msg()+0x438 (section 1 0xF5C8)
(
0x648C5B20native kernel module intuition.library.kmod+0x0001824c
(0x648C5B80native kernel module intuition.library.kmod+0x00018470
(0x648C5C00native kernel module intuition.library.kmod+0x0000839c
(0x648C5C30native kernel module intuition.library.kmod+0x00008130
(0x648C5CA0_Z18create_applicationPc()+0xd4 (section 1 0x878)
(
0x648C5CD0main()+0x144 (section 1 0x11D4)
(
0x648C5D00native kernel module newlib.library.kmod+0x000020a4
(0x648C5D70native kernel module newlib.library.kmod+0x00002d0c
(0x648C5F10native kernel module newlib.library.kmod+0x00002ee8
(0x648C5F50_start()+0x170 (section 1 0x16C)
(
0x648C5F90native kernel module dos.library.kmod+0x00025208
(0x648C5FC0native kernel module kernel+0x0006acdc
(0x648C5FD0native kernel module kernel+0x0006ad5c


Line 806 for me now is:

804:void Mutex::lock()
805:{
806: ObtainSemaphore((struct SignalSemaphore *) m_mutex);
807:}

Line 55 is:

#include <dos/dosextens.h>

Line 714 is:

712: D(kprintf("currentThread() task %p\n", currentThread));
713:
714: if (ThreadIdentifier id = identifierByThread(currentThread))
715: return id;

Line 214 is:

mainThreadIdentifier = currentThread();


After reboot tried another time, at this time it crashes as before (on wtfThreadData() ), and stack trace point on:

Stack trace:
(
0x655CB940native kernel module kernel+0x0002009c
(0x655CB970native kernel module kernel+0x0002012c
(0x655CB990) [/usr/local/amiga/odyssey-r155188-1.23/BAL/Types/WTF/MorphOS/BCThreadingMorphOS.cpp:246_ZN3WTF19initializeThreadingEv()+0x5e8 (section 1 0x17A9290)
(
0x655CBA10_ZN3JSC19initializeThreadingEv()+0x64 (section 1 0x1509FC8)
(
0x655CBA20_ZL12handleOM_NEWP6IClassPmP5opSet()+0x134 (section 1 0x966C)
(
0x655CBAE0_ZL8dispatchP6IClassPmP4_Msg()+0x438 (section 1 0xF5C8)
(
0x655CBB20native kernel module intuition.library.kmod+0x0001824c
(0x655CBB80native kernel module intuition.library.kmod+0x00018470
(0x655CBC00native kernel module intuition.library.kmod+0x0000839c
(0x655CBC30native kernel module intuition.library.kmod+0x00008130
(0x655CBCA0_Z18create_applicationPc()+0xd4 (section 1 0x878)
(
0x655CBCD0main()+0x144 (section 1 0x11D4)
(
0x655CBD00native kernel module newlib.library.kmod+0x000020a4
(0x655CBD70native kernel module newlib.library.kmod+0x00002d0c
(0x655CBF10native kernel module newlib.library.kmod+0x00002ee8
(0x655CBF50_start()+0x170 (section 1 0x16C)
(
0x655CBF90native kernel module dos.library.kmod+0x00025208
(0x655CBFC0native kernel module kernel+0x0006acdc
(0x655CBFD0native kernel module kernel+0x0006ad5c


And line 246 is :


245:static ThreadReplyStateMap& threadReplyStateMap()
246:{
247: DEFINE_STATIC_LOCAL(ThreadReplyStateMap, map, ());
248: return map;
249:}

Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@kas1e

It sounds stupid, but what happens if you make a copy of the exe and the first time you start the original (owb). And the second time you start the copy (owb_copy).


Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

initializeThreading() seems to call a lot of functions just to initialize static data in these functions, which shouldn't be required, at least in the ones included in the sources there is nothing which can only be done from the main thread.
But if there is a bug somewhere which requires doing that for some strange reason you probably have to do it for everything, for example add threadMap(); syncPortMap(); threadReplyStateMap(); in initializeThreading() as well.


Why are you using
#ifdef __amigaos4__
static Mutex* atomicallyInitializedStaticMutex=NULL;
#else
static Mutex* atomicallyInitializedStaticMutex;
#endif
?
That makes no sense either, but since you added it there must have been something seriously wrong somewhere which required doing it, for example a buffer overflow writing to some .bss data and adding =NULL moved it to the .data section and now something else in .bss is trashed instead.
What was the reason you did that?

Go to top

  Register To Post
« 1 ... 16 17 18 (19) 20 21 22 ... 72 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project