well I had problems with DSI errors when loading Tunenet, but when I changed the order of programs I start after booting, meaning start IBrowse 2.4 before Tunenet and Wookie, all my DSI problems seem to have vanished! Kinda the opposite situation.
I am afraid that the log file shows noting useful in this case. My bet is on some MUI classes, this was already happened in the past. (Namely with textedit.mcc.)
When I used shared memory instead of public something trashed the JIT descriptor in the task structure and some tasks are crashed with it. I couldn't find anything related to Petunia, so the "workaround" was to change the shared memory to public. But now public memory is gone, I couldn't reproduce these memory trashing anymore. (The newmem system organizes the memory pieces significantly different than the oldmem did.) Yet, some strange things happen with the 68k MUI classes eventually. I have no explanation for the behavior.
You might try to add all 68k MUI classes to the blacklist as a test.
Other than whats already been said a hundred times, no not really
IBrowse forked just prior to 2.3's release into two branches, IB2.4 and IB3.0.
The IB2.4 branch was, originally, just for some quick fixes and the plugin API.
The 3.0 branch was ported to GCC, built as PPC native and re-write work began.
The 2.4 branch was then to be back ported into IB3.0.
Oliver and Stefan were working on 2.4, Meldon and Stefan were working on 3.0, I was working where ever I could help.
With the delays and complications during 2.4, plans changed and 2.4 became slightly more than planned. Meldon got a full time job and Stefan had other commitments so development work on 3.0 slowed right up. Meanwhile Oliver and I concentrated on 2.4.
With the release of 2.4, the plans to back port 2.4 into the 3.0 branch changed due to the insane amount of changes in 2.4, so instead the 3.0 branch is being back ported into the 2.4 branch to form the new 3.0 branch. Then we can restart 3.0 development in earnest.
How big a task is the backport from 3.0 to 2.4? I'm just curious as to how much work has already gone into 3.0 (e.g., is there some kind of CSS engine yet). I hope you guys can get version 3.0 done faster than it took to complete version 2.4.
Not sure tbh, I wasn't involved in the 3.0 branch so I don't know how much was changed.
Quote:
I'm just curious as to how much work has already gone into 3.0 (e.g., is there some kind of CSS engine yet).
See above, but I know the layout engine is mid-rewrite. How much is left to do in that particular area, I have no idea. Seeing as IBrowse was my first experience with C and AmigaOS programming, a lot of it is out of my reach still - I tend to play about with the GUI and prefs, hence the Search Bar etc, while the others spend time on the important bits.
Quote:
I hope you guys can get version 3.0 done faster than it took to complete version 3.0.
That will be ... impressive
To the best of my knowlegde we are still planning something like bi-annual public betas for IB3.x, but thats subject to Stefans decision.
Quote:
BTW, has the plugin API been published yet?
Not really - the plugin is based on the NSAPI4 SDK, so to a degree there is some stuff available, but not Amiga/IBrowse specific. Its the next thing on Olivers list, along with a skeleton plugin and the source to the Flash plugin, but he is having a rest atm.
Hans wrote: How big a task is the backport from 3.0 to 2.4? I'm just curious as to how much work has already gone into 3.0 (e.g., is there some kind of CSS engine yet). I hope you guys can get version 3.0 done faster than it took to complete version 2.4.
Back when 2.3 was released, both the 2.4 and 3.0 branches were initially based on the 2.3 sources. And there has been far more changes for 2.4 in comparison to 3.0. So, it's going to be much faster to back port the 3.0 sources to 2.4 than vice versa - that's about the only reason it's being done that way . The back port is not really that big a task at all, in comparison to CSS, for example.
AFAIK, Meldon wrote the CSS parser some time ago, and it should be pretty much working. That said, the parser is the easy bit - it's the linking of that into the layout code which is the tricky bit, and linking to the JS DOM interface (although this is more time consuming than tricky). As Dave said, the layout engine needs to be rewritten for 3.0.
I noticed that my crashes were always on startup - the screen was opened, the GUI drawn fully and the DSI happens when my Home Page is being fetched.
I've checked with Petunia disabled and I've had crashes just the same, so I don't think it's a Petunia problem. I've given the CPU a dust and a bit of TLC (core voltage re-adjusted). It's also gone from a single 256 MB DIMM to a single 512 MB DIMM.
I continued to get the exact same DSIs, so I think I have ruled out Petunia, CPU and memory problems.
For the last week I've had the Home Page nulled to Blank: and no crashes. I've been waiting until everything is loaded and ready, then fetching the Home Page manually (by clicking on the Home icon). No crashes for a week.
However, I've just had another crash (DAR = 0x4E8 as usual), this time when fetching the Home Page. Could Someone Who Knows These Things have a look at the HTML code and tell me if there is any Javascript in it or linked to? Frankly, I wouldn't recognise Javascript if it popped up in my porridge.
As to going back to "defaults" - I haven't tried it yet because the system will be unusable in its default condition. I might make up a new OS4 Final build that is as "default" as it can be and still access the network, etc.
Like you, I've had the same problem & I keep trying different things. For a month now I've had very few GRs. What seemed to help was to turn off the disk cache & put IB on the black list. I still have IB on the black list, but I've since set up the cache in ram: so it's not saved if I turn the system off. I'm wondering if there's a bug in the cache when using the SFS file system. The recoverable alert on quitting seems to be with the new memory system.
Look, only one leg, count em, one! X1000/PA6T@1800MHz/2Gb/Radeon 4850
It may sound like a lot of work, but during beta testing (of 2.3 iirc) we had one crash bug which took forever to track down and in the end it was a bug in NewString (no suprise there!) which was only triggered when the cursor was set to flashing and the time delay was set to a certain value.
what value was that? I get a crash bug every now and again, maybe once a week, but apart from that its quite solid. I just changed my newstring prefs and turned the blinking off completely. It was set to 500ms I think.