Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
163 user(s) are online (148 user(s) are browsing Forums)

Members: 0
Guests: 163

more...

Support us!

Headlines

 
  Register To Post  

« 1 ... 17 18 19 (20) 21 22 23 ... 72 »
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
Just can't stay away
Just can't stay away


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
Just can't stay away
Just can't stay away


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
Just can't stay away
Just can't stay away


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
Just can't stay away
Just can't stay away


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
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

The crashes seem random from those logs you posted.

But something is getting trashed.

I would suggest you go through all amiga specific structure allocations and check they are all the right size, there's an outside chance of an allocation of a pointer to struct rather than a struct or something like that. (ie sizeof(struct foo*) instead of sizeof(struct foo) very easy mistake to make and hard to spot ... and you rarely get a DSI from such errors.


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


See User information
@broadblues

Quote:
I would suggest you go through all amiga specific structure allocations and check they are all the right size, there's an outside chance of an allocation of a pointer to struct rather than a struct or something like that. (ie sizeof(struct foo*) instead of sizeof(struct foo) very easy mistake to make and hard to spot ... and you rarely get a DSI from such errors.
If it would be something like that he'd get random crashes no matter how he starts Odyssey, but not never crashes for the 1st run and always for the 2nd in the same shell.

Some cleanup seems to be missing somewhere which results in destroying something, or even more likely setting it to some data of Odyssey which is freed after exit, in struct Process or something else the shell is using.

@kas1e
Use tools like Ranger or Scout to check the struct Process of the shell you are using for starting Odyssey, nothing must change after the 1st run but something probably does. Knowing what is trashed would help a lot.

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


See User information
@Georg
Quote:

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).


Same crash (i.e. run owb, then exit, then owb_copy), same crash, same stack trace.

@joerg
Quote:

Why are you using
static Mutex* atomicallyInitializedStaticMutex=NULL;
What was the reason you did that?


We add it with Deniil few years ago, and all what i found now in the logs is just some irc quote:

Quote:

[23:49] <Deniil> this line:
[23:49] <Deniil> static Mutex* atomicallyInitializedStaticMutex;
[23:49] <Deniil> should be static Mutex* atomicallyInitializedStaticMutex=NULL; I think
[23:49] <Deniil> because in initializeThreading() there is if (!atomicallyInitializedStaticMutex)


So we imho add it just in case, and now i remove it back, and do check : all works as before: i.e. crash on second time as well.

@joerg
Quote:

Use tools like Ranger or Scout to check the struct Process of the shell you are using for starting Odyssey, nothing must change after the 1st run but something probably does. Knowing what is trashed would help a lot.


before start anything:
http://kas1e.mikendezign.com/temp/joerg/01_before_anything.jpg

start of odyssey first time:
http://kas1e.mikendezign.com/temp/joerg/02_run_first_time.jpg

quit from odyssey:
http://kas1e.mikendezign.com/temp/joerg/03_quit_from_odyssey.jpg

start of odyssey second time:
http://kas1e.mikendezign.com/temp/joerg/04_second_run.jpg

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

No idea what it is, but "MUI imagespace screen notify" child process is still running after exit, and it's still waiting for some signals which shouldn't happen either.

Using something like Scout instead of Ranger would be better, it includes much more things from struct Process like the Input(), Output() and ErrorOutut() files (pr_CIS, pr_COS and pr_CES), current directory lock, etc.

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


See User information
@kas1e

Very early in prog startup in main() try

FindTask(NULL)->tc_UserData = NULL;

(or if you changed BCThreadSpecifcWTF.cpp to use something else than tc_UserData, try to NULL that).


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


See User information
@Joerg
Quote:

No idea what it is, but "MUI imagespace screen notify" child process is still running after exit, and it's still waiting for some signals which shouldn't happen either.


Dunno what is exactly, but that thing leaves from any mui app after exit (if i even run for example wookiechat, or amirc, or anything). So imho should be not relaed.

Quote:

Using something like Scout instead of Ranger would be better


Tried one from os4depot, and once run and press on Tasks it just crashes.

@Georg
Ok, will check now

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Sent a working scout by email.

If you try Georg's experiment print out the value before NULL ing just see what changed if anything.


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


See User information
The scout I sent you was 3.5 but 3.6 from os4depot also works for me so could be a machine problem.


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


See User information
@Andy
Same crash with your scout too , but its probably because i am on debug kernel + munge , and DAR are: CCCCCCD0 (so its munge then). Ignore dsi help through. Will try now.

@Andy, Georg
I have for now:

BTThreadingWTF.cpp:

Quote:

NewThreadContext* context = reinterpret_cast<NewThreadContext*>(IDOS->GetEntryData());


What should i "null" ?

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


See User information

Go to top

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

 




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




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project