Opus Magellan source is free now!

@LievForIT
Quote:

yep, thats about i think as well

@all
Anyone who in interest and want to help with working on dopus5, be aware that there is forums now

@liveforit
I put prinfs now in all the CASEs, right at begining, and so far i see that 2 cases happens: firstly IPC_SHOW+LISTER_OPEN: (they both togeter in one case) - that open a lister , and i see it. Then, on next loop it do new getmsg, going to case LISTER_BUSY, deal with it fine, and then crash happens on IPC_Reply.

Thats what i have once i do prinfs %p before/after getmsg at top of loop, and before/after ipc_reply at bottom of loop:

lmsg pointer before GetMsg, before "while" = 00000000

lmsg pointer after GetMsg = 67FAE488
WE ARE IN case IPC_SHOW: + case LISTER_OPEN:
lmsg pointer before IPC_Reply = 67FAE488
lmsg pointer after IPC_Reply = 67FAE488

lmsg pointer after GetMsg = 664F36D8
WE ARE IN case LISTER_BUSY:
lmsg pointer before IPC_Reply = 664F36D8
CRASH-DSI
lmsg pointer after IPC_Reply = 664F36D8

So, seems GetMsg works, get address, and replyes sends to the same addresses. Just by some reassons, it seems that IPC_SHOW: case passed fine, then, it goint to LISTER_BUSY, with repeating GetMsg/IPC_Reply combo and crashes on IPC_Reply. While addresses seems ok and the same..

I also tested the same binary on morphos, and its all looks the same by prinfs and logic. I.e. the same IPC_SHOW+OPEN_LISTER, reply, getmsg, LISTER_BUSY, reply, getmsg, and contnue to other cases like LISTER_SET_LOCKER, LISTER_SHOW_SPECIAL_BUFFER and so on.

LISTER_BUSY by itself looks like this:


Dunno if that code can blow all up. For tests i just comment whole code in LISTER_BUSY, and only keep "break" => still crash on reply after that. Like something wasn't set , but should be set.

ps. all of this mean, that there is no 4 times replyes, its just for every reply it go to some case. And in end one getmsg = one reply, all is fine. Just on os4 its trying to brings to few cases after crash (to busy and so on), and then freezes.

@kas1e

"sc:c/sc RESETOPTS NOMULTINCLUDES NOOBJECTNAME MGST=include:all.gst sc:source/all.c"

Ah! That works. Thank you!

Please let me know if there is anything I can do to help you solve the lister (message) problem.


Scott

@Scott
Quote:

Only if you will help with printfs/logic debugging :)

I find out one more interesting detail, there is IPC_SHOW: + LISTER_OPEN: code:



If we comment out Reading of device list + lister_smart_source, then, lister spawns (empty of course, without list of files, as we disable it). And i can navigate via lister's menu. Through, at this moment, there is no repeating of 2 or 3 times of getmsg/ipc_send. Only one time it come to IPC_SHOW, and then back to main FOREVER loop.

I can resize window, press buttons: everything works (and for that moment , its never going to the while ((lmsg=(IPCMessage *)GetMsg(lister->ipc->command_port)) && !quit_flag) loop.

I even can go to the "EDIT" of filetypes from lister , and it will spawn a new window, and all works. And i can see, that when it happens 3 times repeats GetMsg / IPC_send, and come to differen CASEs, and no crash happens.

So, its somehow come to the way of how initial lister opens and read devices,etc, which in end (seems so) make IPC_send crashes. But that only guess, as pretty possible it happens because of how lister opens at all (i mean whole lister_open() , with all those IDCP gadgets, etc).

It might be a random crash due to fact that the message is custom, so maybe they did not allocate right amount of memory for the custom messages.

It should be SizeOf(struct IPCMessage) and not SizeOf(struct Message), I defiantly try to look for SendMsg(), to see if they are creating messages whit wrong size.

@kas1e

Interesting....

In lister_proc.c I just tried commenting out the code you mentioned like this...

// Read device list?
/*
if (flags&LISTERF_DEVICES)
{
function_launch_quick(
FUNCTION_RUN_FUNCTION,
def_function_devicelist,
lister);
}

// Otherwise, check source/dest
else lister_smart_source(lister);
*/

and rebuilt....but it still behaves exactly the same - dsi errors in the same places. Is there something I did not do correctly? You mentioned that you wre able to open lister windows with this change and not get errors. Is there something else you did too?
I also recall someone suggesting that it is the changes in the OS4 icon.library that is somehow responsible for the Opus Magellan lister errors. Have you tried commenting out the code that creates the icon strip in a lister and see what happens?
Just a thought....

Scott

Hmmm..

It appears to be an issue with the read_directory function.

When I comment out the line that calls read_directory in lister_proc.c (lines 521-524 of lister_proc.c) I can open and close listers. They default to icon type and show nothing, but I can use the right mouse button to change them to list type, and the refresh shows the lister icons etc.
When I enter a new path in the line at the bottom of the lister, it calls a different call to read_directory and we see the infamous DSI errors in OS4.

So the problem seems to be something in read_directory.

Scott

@Scott
How you run/open listers ? I do it like this : RMB for menu on dopus screen, then Lister->New. That line with read_directory() which you comment, are in "case LISTER_INIT:", in which i by my way of opening listers do not come, but you come to it when you dbl-click on volumes.

So, if you spawn a listers by dbl-click on volumes, then in that case code will do "case LISTER_INIT:" and your comment will take place. And if you do it like this, that can explain why nothing changes for you after my previous comments.

I.e. when you do just RMB-Menu/Lister/New , its do:
IPC_SHOW+LISTER_OPEN: , then LISTER_BUSY , and crash after

And when you dbl-click on icon, its starts from LISTER_INIT, then LISTER_MAKE_SOURCE, then LISTER_BUSY, and somethere after that crash as well.

@liveforit
Quote:

I didn't found any "sizeof of messages" in the whole lister* files. Not any sizeofs of struct IPCMessages, not in opposite.

Quote:

You mean IPC_Reply() ? And where you mean to check messages sizes ? Sizes of lmsg when IPC_Reply happens and sizes of lmsg when we do GetMsg ?

Quote:

The message wont be allocateing in IPC_Reply() but in IPC_Send() (or whatever it's actually called) maybe not even there but in the function that calls the send function.

They *might* be allocating on the stack with autmatic variables, in which case you wont find a sizeof.


It's sounds to me from the comments though that your issue is more likely in the directory reading code. It wuldn't be the first bit of 68k software that's screws up in related areas. AmigaOS4's memeory protetion trips up stuff that 68k environments won't.

Look for this read_directory funtion that was mentioned.

@Andy
Quote:
Commented all the code inside of that function and:

1). When i dbl-click on the volumes, empty listers spawns, but nothing inside. And i can close them

2). RMBmenu->Lister->New = the same crashes as before. i.e. read_directory not involved, but involved some sort of read_devices, which disabling also remove crash.

read_directory and read_devices are likelt to be similar in nature, study them you'll likely find your bug.

AAAA !!! SUCK MY AMIGA !!!

! press for screenshot !

there is new bin+library (i also disable there waiting for registration details, but forget to disable first window, but its anyway faster than with delay).

fix are from Georg Steger (i do not know who he are for now), and fix related to getting away from PF_ASYNC. If he will be ok with i will drop his mail here with details.

@kas1e,Georg Steger
Wow, fantastic. So rapid. Thank you so much !!!!

Tears

Your work is very much appreciated folks, thank you!

@kas1e

Well done Roman !

Well done.

So now it’s just work of converting it to GCC, and adding 64BIT dos support and replacing this ugly icons, and then toolbar should be updated to support PNG images, and maybe some gradients on the buttons.

@LiveForIt
Quote:

Yep, there is already few ppls who in big interst with all of this, but my bet is that Itix can be first one and faster one.

For first we (not me of course, those who skilled enough, like Itix, Jens and co), will rewrite dopus5.library - the harder part. Then once it will be done, it can be tested together with 68k binary of dopus. If all will going well, then dopus itself, modules and so on.

And then, when everything will be the same and works with gcc and builds on mos/os4/aros, we can start add os specific parts, replacing uglynest, add mouse wheels, and so on.

Well the OS4 version of Dopus5.library will need some Interfaces, and stub functions; I’m not shore MorphOS changes to the code will help whit that.

@kas1e

The files in that archive simply crash on startup.


How are you running it?