Beta testing

@tlosm

Crashing in what way ? What app ?
You need to be specific, all i can suggest is to save the log and then mail Alfkil with all the details on how and what to do to reproduce the issues and so on ..

@samo79


just a fresh crash.

this is from juffed

Symbol info:
Instruction pointer 0x01A5B398 belongs to module "newlib.library.kmod" (HUNK/Kickstart)

Stack trace:
native kernel module newlib.library.kmod+0x000032d8
_ZN9QListData6removeEi()+0xc0 (section 10 @ 0x86248)
_Z13processParamsR6JuffEd11QStringList()+0x168 (section 8 @ 0x23E20)
_Z9runSingleiPPc()+0x840 (section 8 @ 0x28DBC)
main()+0x1f4 (section 8 @ 0x2973C)
native kernel module newlib.library.kmod+0x000020a4
native kernel module newlib.library.kmod+0x00002d54
native kernel module newlib.library.kmod+0x00002ee8
_start()+0x170 (section 8 @ 0x16C)
native kernel module dos.library.kmod+0x00024f18
native kernel module kernel+0x0004357c
native kernel module kernel+0x000435fc



but the same problem is in stellarum , easy paint ...

The Guillaume porting run great no crash for now there:)
melite work great too ;)

@Chris

Is this what you are after?

http://img547.imageshack.us/img547/1796/nxmy.png

@tlosm

You may try increasing the stack... however if the Guillaume apps still working it's more liking an issue in that specific apps, not in Qt

@alfkil

Quote:

Yaiii !! ...

@samo79

Nope stack raised and Stellarium continue crashing my system :-/
ok this app will be putted in the forget drower

@tlosm

Don't do that, just ask Chris to do a rebuild, that should solve the problem. Well, wait a few more days to ask him, he will need the latest Qt release. :)

@alfkil

if the king Alfkil say something i have to belive it ... and in italian i reply to the king: Vaaaaaaaaa Beeeenneeeeee

Translated: OOOOOkkkkkkkkk 8)

@Chris
For the Workbench paths who are opened in MUI-OWB,
I have, like you, made some bypasses in QtWeb, smTube, ClipGrab and InternetSurfBoard by using an external REXX called by startDetached.

This REXX "amigaizes" the unix path and opens it.

It's not nice, a dirty amateur way, but at least it works well !

@alfkil

Quote:

Yes

@alfkil

Quote:

If people can round up whatever needs recompiling I'll do them all in one go. I'd heard FracPlanet isn't working either although I'm not sure whether that's correct.

@zzd10h

Quote:

I've done no such thing
I only noticed the feature today.

@zzd10h

Actually, there is a function in libQtCore.so, that translates path names. I think it is called qt_unix_to_amiga_path_name(const &QString) or something else ridiculous. And of course I told noone about it, and it is not in any of the headers... Anyway, I think I should have actually done it another way, that there are some functions in the corelib that is supposed to handle local path names and translations hereof, but I didn't look into it when I started the point, and my own bad solution has stuck. Something to look out for in Qt5, I guess.

@tlosm
"The Guillaume porting run great no crash for now there:)"

Ah ah, it must be a piece of chance ;)

@alfkil
With this function, I wil justl "amigaize" the unix path, true ?

But it will not open the workbench drawer.
I tried the QDesktopServices::openUrl function to open drawer but without success. It is why I used a dirty REXX method.

@zzd10h

If launch-handler it will, if you use this: http://www.unsatisfactorysoftware.co. ... wnload.php?file=wbopenurl

There's an extra stage of clicking WB, in theory you could get into an infinite loop if the web browsers are disabled, so I wouldn't recommend that.

Doesn't help until Alfkil releases the update of course.

Hi Alfkill :
With the last version of ClipGrab (3.3.0) it seems that I have to use QThread.
But it fails in the QThread::start function (tested under QF8 and latest from SourceForge).

Do you know if you have implemented it ?

http://harmattan-dev.nokia.com/docs/library/html/qt4/qthread.html

If not, I will have to review the download process to reimplement the older one who worked :(

Thanks

Crash log for task "pthread id 4"
Generated by GrimReaper 53.16
Crash occured in module libQtCore.so at address 0x7BCFC134
Type of crash: DSI (Data Storage Interrupt) exception


Symbol info:
Instruction pointer 0x7BCFC134 belongs to module "libQtCore.so" (PowerPC)
Symbol: _ZNK5QFile8fileNameEv + 0x1C in section 10 offset 0x00144130

Stack trace:
_ZNK5QFile8fileNameEv()+0x1c (section 10 @ 0x144130)
_ZN12ffmpegThread3runEv()+0x134 (section 8 @ 0x11BEC)
_ZN14QThreadPrivate5startEPv()+0x100 (section 10 @ 0x49D08)
run()+0x278 (section 1 @ 0x410C)
ThreadCode()+0x35c (section 1 @ 0x44B4)
native kernel module dos.library.kmod+0x00024f18
native kernel module kernel+0x00042514
native kernel module kernel+0x00042594

@zzd10h

I don't think the crash is due to QThread. Looks like something happens in QFile, judging from the stacktrace. What is the code inside the ffmpegThread::run() implementation?

@zzd10h

C++ and threading doesn't work on AmigaOS

If your code throws an exception for any reason it's doomed

If your code doesn't use exceptions you may be okay, but there another feature not supported as well (RTTI I think)

@broadblues

Why not?? I have the first 100 examples of Qt apps using threading, that work just fine. Just because some single feature (exception handling) does not work, does not mean, that threading per se is unusable. As I said, judgting from the stacktrace, the problem is not in the thread handling but in the file system handling. And that can be solved.

@alfkil

If you carefully write your code avoiding exceptions and RTTI it'll work, sure.

Avoiding exceptions is tricky when porting and if threaded c++ code goes haywire it's something to look out for.

If one thread does not need to access global state (e.g. deallocate memory from another thread), then it is possible to work-around the C++ threading issue, such that RTTI & Exceptions work. I've done it in PortablE (while I use C++). However it is a major hack, which MAY stop working whenever AmigaOS goes multi-core.

Email (not PM!) me if you are interested in this kludge

EDIT: Changed "will most likely" to "MAY".