I have not downloaded and installed all version throughout time. Can I have missed an .so that is not included now anymore??
No, all required shared objects are included in the Aminet 1.21 archive, 1.23 additionally needs libowbfont.so and 1.24 libowbbookmark.so which are included in the updates. Make sure you either have the updated libgcc.so and libz.so in the OWB directory or in SOBJS:, if you don't have them in one of both places the old versions included in OS4 would be used and crash.
A popup/requester showing until the main GUI is opened at startup so one knows that it is starting... Maybe with version information?
I just tested it and I'd have to add a long delay before opening the window to be able to read anything like the version number, without adding a delay it's displayed less than 1/20 second before the main window is opened on top of it.
I don't want to step on anyones toes, but i still call the shared objects implemetantion broken...
It's not, it's working without any problems for hundreds of users, only you and 2 or 3 others have problems, and in your case with the random ISI crashes which always look like they could be caused by wrong or incomplete data cache flushing or instruction cache invalidating I guess it's the 7457 CPU which, like nearly all others, would need special support (settings, code or even workarounds for specific bugs) in the AmigaOS4 kernel. Maybe I'm wrong and there is special support for the two 7457 revisions used by ACube for the CPU module repairs in the OS4 kernel already, but I doubt it.
Hmm, granted, i have a cpu module which isn't the norm out there, but why do i have problems *only* with OWB, not a single other program shows this behaviour or even crashes at all?
I can't unfortunately test another program that takes heavy use of shared objects, but (and i tested this with two of the projects i try to take care of) whenever i tried to build them with shared objects they tend to crash/show weird behaviour/freak me out with all sorts of mischief ... figure.
Anyway, as i said, i don't want to step on anyones toes
I'll keep my feet still and wait for a) the new SDK and b) the next update of OS4 and test then again
...mumbles, i still think its the shared objects...
Edit: Oh, yes, i completely forgot (but you already know that i think?). When i have done some work with other programs (i.e. YAM, AWeb, Wookie and such) and overall some actions were taken in other programs than OWB chances are that OWB will THEN come up nicely without complaining
So, theres another thing theat would point *me* to not yet loaded/initialized/opened/prepared to use .so files... ...but of course, i'm not a coder and know nothing about it
For me, from the time I double-click the icon it is at least 5-6 seconds of nothing until the GUI appears. (Well, it prints 'trying to start program "OWB"' at the top and the CPU meter goes 100%.)
Maybe it's just the big exe that are loaded in that time... Still would be nice to have something that shows that it is trying to start directly after double-clicking... Maybe I'm not used to have such a big (and good!) program loaded on the Amiga! :)
It is almost certainly the executable and all the shared objects (and maybe some libraries and fonts too) that takes the time. I imagine the window opens as soon as it can, and a splash screen couldn't open much sooner (as Joerg confirms).
The answer would be to have a separate OWB_Launcher that reads the tooltypes, displays a splash screen and opens OWB with the correct arguments. It would then have to close the splash screen (or OWB would).
For me, from the time I double-click the icon it is at least 5-6 seconds of nothing until the GUI appears. (Well, it prints 'trying to start program "OWB"' at the top and the CPU meter goes 100%.)
Maybe it's just the big exe that are loaded in that time...
Yes, it takes that long to load and relocate the about 22 MB OWB executable, until it's loaded (completely, incl. all shared objects) it obviously can't do anything, and after the first code of OWB is executed it takes less than 1/20 second here until the window is opened.
Quote:
Maybe I'm not used to have such a big (and good!) program loaded on the Amiga! :)
I can't unfortunately test another program that takes heavy use of shared objects, but (and i tested this with two of the projects i try to take care of) whenever i tried to build them with shared objects they tend to crash/show weird behaviour/freak me out with all sorts of mischief ... figure.
Only on your system, or did you sent such executables to others for testing as well?
Quote:
Edit: Oh, yes, i completely forgot (but you already know that i think?). When i have done some work with other programs (i.e. YAM, AWeb, Wookie and such) and overall some actions were taken in other programs than OWB chances are that OWB will THEN come up nicely without complaining
So, theres another thing theat would point *me* to not yet loaded/initialized/opened/prepared to use .so files...
If shared objects would be like AmigaOS libraries and kept in RAM that could be that case, but they aren't, at least not yet, they are not keept in RAM and are not shared, they are reloaded again every time something is using them and each executable using them gets it's own copy.
Quote: I can't unfortunately test another program that takes heavy use of shared objects, but (and i tested this with two of the projects i try to take care of) whenever i tried to build them with shared objects they tend to crash/show weird behaviour/freak me out with all sorts of mischief ... figure.
Only on your system, or did you sent such executables to others for testing as well?
Certainly. One G4 and one G3, both crashed and we couldn't figure out why. Well, we could say that the pthread .so was the culprit, but, as i said, being no coder i haven't had a chance to try to corner it, it didn't work, so i went back to when it worked
One G4 and one G3, both crashed and we couldn't figure out why.
Did you strip the executable, or a shared object it's using? If yes that's the reason: strip destroys shared objects and executables using shared objects. If not: Do you have a small example you can sent me for testing?
Probably not really much more helpful, but if I run OWB three times and ignore the first two GR's, it finally works. Of course I then have to reboot if I want to use any other programs.
Edit: Btw, by ignore I mean I don't even touch the GR popup window at all. I just leave them up.
Edited by Valiant on 2008/5/8 16:11:27
Valiant@Camelot AmigaOne XE, 800Mhz, 1GB, 9250 Radeon, OS4.1u7 Sam440ep, 666Mhz, 512Mb, 9250 Radeon, OS4.1u6 A1-X1000, 1.8Ghz, 1GB, 9250 Radeon, OS4.1x A1-X5000/40 2.2Ghz, 2GB, Radeon HD 7700, OS4.1 FE ud 2
Not sure if this is the same thing, but I encountered some weird stuff tonight.
If I get a GR showing DSI error, and hit ignore button, the next program I run acts weird.
For example, Final Writer 97 gets stuck while loading and comes up with a strange message in a requester. Another example, Partiion Wizzard comes up listing the a1 parallel port or a1 serial port (instead of disk partiitions) and then hangs. I have to reset the machine to get it back to normal.
I'm not sure if this happened with v 1.18 because I usually reset the machine if I got any kind of GR from any program.
BTW, I always get a GR showing DSI error if I launch OWB and quit before I visit a website. Maybe its related to having no "home page". Tooltype = (HOME=http://amigans.net/)
--- redfox
Edited by redfox on 2008/5/8 4:55:00 Edited by redfox on 2008/5/8 4:57:36 Edited by redfox on 2008/5/8 5:18:57 Edited by redfox on 2008/5/8 5:20:19
One thing I've noticed is that if the webpage is longer than the OWB window and I scroll down to view some more of the webpage, then hit the back button or go to another webpage, the old one shifts down momentarily before the window updates. This is especially noticable if the window has a photo. The photo moves just before the window updates to the previous webpage or next webpage.
Go to this webpage. Click on photo of CPU to enlarge the photo. Scroll down part way so the top of the photo is cutoff by the top of the OWB window. Hit back button to go back to previous webpage.
On my machine, the bottom part of the photo drops down, then the window updates to the previous webpage.
With OWB 1.18, I see the window clear (can't remember if it goes white or black) before it updates to the previous webpage.
It is a minor thing, but it caught me off guard until I realized what was happening. It happens in v1.21 as well.
Not addressing the case with OWB specifically, but generally speaking, if you choose to ignore DSI errors, you risk running into system instability.
I'll keep that in mind. Usually I reset the machine after I get any kind of GR. Been there many times before during the last few years. This was just a "what if I just hit the ignore button and carry on" senario and I was able to reproduce the results.
On some sites, scrolling up and down makes the page disappear. this seems to be doing it consistently- scroll down and there is nothing new, scroll back up and what was showing has now gone.
I find with 1.24 that when signed onto Yahoo groups if I scroll the down then back up the top of the page has been blanked out. Parts come back if i place the mouse pointer over them, but not the whole blanked out section.
renoir
g4 933mghz (came that way not overclocked) 512 mb ram 2 40gig hds.
I told before that facebook works. However when i try to compose a message and then push the "send" button nothing happens. Same if i use tab to select the button. It gets selected but hitting return/enter doesnt do anything so the message doesnt get sent.
Fixable or is there some workaround with special keys :)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
