Threading library for optimising compiler

agraham

Expert
Licensed User
Longtime User
NullReferenceException at Threading.Thread.wrapper()
To get that far (into the internal wrapper method) version 1.4 has checked that your thread sub exists and has called it so I think the problem is in the B4ppc code that is running as a thread. It looks like it is trying to access something that is not there. If you can't find it then post a version of your project that shows the problem and I'll take a look.
I already regret to have upgraded to 6.50, because instead of working further on my project i'm spending time now on chasing errors and exceptions i did not have before
I don't know why you are having problems, I found the upgrade just worked in general, except where I had to modify some of my libraries to cater for the new module naming scheme.
so i cannot roll back to 6.30 now.
Have you been naughty and not kept backup copies of older versions of your project? You possibly could retrograde with some effort but I wouldn't advise it. The upgrade will be better in the long run as you benefit from bug fixes as well as new features. Despite the problems you are having with the upgrade I have found nothing intinsically less stable with 6.50 than previous versions.
 

TWELVE

Active Member
Licensed User
Quote:
Originally Posted by TWELVE
NullReferenceException at Threading.Thread.wrapper()

To get that far (into the internal wrapper method) version 1.4 has checked that your thread sub exists and has called it so I think the problem is in the B4ppc code that is running as a thread. It looks like it is trying to access something that is not there. If you can't find it then post a version of your project that shows the problem and I'll take a look.

That sounds logically, but the same code compiled under 6.30 did not throw this exception.To verify this again, i compiled a version 2 steps back ( the source is definitely in the 6.30 format), but the error still occurs with this older version which is proven to run fine under 6.30.

From my point of view, this can't be an issue of my code, which ran fine this way under 6.30.It might be, that 6.50 was undergoing some changes which made my code now wrong or invalid somehow.At least something has changed under 6.50 and/or in combination with the threading lib.

By the way, the desktop exe is also crashing at the same point.

I placed someThread.FireThreadEvent at certain points within the thread code, also one at the first line of thread code, but none of these gets actually ever called.So i assume, not one line of the thread code is ever executed.

I call the thread this way:

B4X:
Sub Timer2_Tick

Thread.New1(B4PObject(1))
If Thread.Start("mythread") Then
PrintX("Thread started") <--- appears in the log, then the program crashes
Else
PrintX("Thread NOT started..!")
End If

End Sub


So the thread is started, but crashes immediatly, before it can execute the thread code itself.There's no evidence at all, that the thread is processing only one line of code.


Quote:
I already regret to have upgraded to 6.50, because instead of working further on my project i'm spending time now on chasing errors and exceptions i did not have before

I don't know why you are having problems, I found the upgrade just worked in general, except where I had to modify some of my libraries to cater for the new module naming scheme.


That might be true on the surface, but i also updated my other ( windows-) compiler and i'm facing a couple of issues there as well.It depends on what features is one using, if somebody is not using threading, he can't have issues related to that...

Quote:
so i cannot roll back to 6.30 now.

Have you been naughty and not kept backup copies of older versions of your project?

Unfortunately it looks like you're right.Most likely i did not realize, that 6.50 would change the source format and - furthermore - would autosave my source to 6.50 format.Nevertheless - that's nothing i can roll back anymore.

You possibly could retrograde with some effort but I wouldn't advise it. The upgrade will be better in the long run as you benefit from bug fixes as well as new features.

That's also my point of view, so i never fear to upgrade to newer versions..;-)
There's no way back, upgrade, fix issues and go on.That is what i'm trying now, even though i don't like that at the moment, because i intended to place some minor bug fixes in my source, which i determined on my vacation recently.

Suggestions still very welcomed....

kind regards,

TWELVE


Edit: i removed all code lines from my thread code, except these:

B4X:
Sub mythread
 
End Sub

The behaviour remains unchanged, this leads me to the assumption, the thread code itself cannot be the cause?


Edit2: i removed 6.50 and installed 6.30.Then i compiled a source 2 versions back and it ran like a charm.So my bad bad code appears to run fine under 6.30 and threading lib 1.2 ..?


Edit3: i replaced the threading lib 1.2 with 1.4 and my program still runs fine when compiled under 6.30.So this is definitely an B4P 6.50 issue.I can't see what's happening under the hood, but i would say sorry Andrew for blaming your library...!


Edit4: i'm a bit curious..after deinstalling 6.30, deleting all related files and directories, i reinstalled 6.50 and the error is gone now..??? My program code is running as normal as before on desktop and device...?
 
Last edited:

agraham

Expert
Licensed User
Longtime User
after deinstalling 6.30, deleting all related files and directories, i reinstalled 6.50 and the error is gone now..??? My program code is running as normal as before on desktop and device...?
Good :). I have to say that as a cautious (nay pedantic!) person I never install a new version of any app. over an old one if I can help it. I always de-install the old and re-install the new because in the past (not with Basic4ppc but in general) I have had problems with "in place" upgrades". This was probably due to experiences in the very early days when the Windows installer/deinstaller was more primitive than it is now - but old dogs and new tricks!

Out of interest did you originally install 6.50 over 6.30?
 

TWELVE

Active Member
Licensed User
Good . I have to say that as a cautious (nay pedantic!) person I never install a new version of any app. over an old one if I can help it. I always de-install the old and re-install the new because in the past (not with Basic4ppc but in general) I have had problems with "in place" upgrades".

I upgrade program versions whereever this is possible.This is to keep my settings and have the new versions upgrading these to the new version.Some do this automatically, others ask me and another will not allow for it.

This was probably due to experiences in the very early days when the Windows installer/deinstaller was more primitive than it is now - but old dogs and new tricks!


OK..i never upgraded windows :) for some known reasons.

Out of interest did you originally install 6.50 over 6.30?

Yes indeed ! Basic4PPC seems to recognize this because it creates a new folder for the version and removes all files from the old one except the lib folder and the .ini file.There was no warning, no comment, so i could see why i should deinstall the old version prior.

The effects i experienced with this are very strange and do not point to the compiler at all !

Since upgrade is apparently not safe, the installer should prevent the user from upgrading the Basic4PPC.For example, the VLC installer first removes the old version and installs then the new version.

Furthermore i do not fully understand yet, why it is not possible to keep multiple versions of B4P installed in parallel.I know a couple of programs, where this does not pose any issue.

Nevertheless i thank you for your comments and help on this !

regards,

TWELVE
 

agraham

Expert
Licensed User
Longtime User
Version 1.5 posted. This is a bug fix for an earlier change I made to the Process object that exposed a difference in behaviour between Process on the desktop and the device. If CloseMainWindow was used on the device it appeared to throw a "No process found" exception. Actually it didn't, it was the .NET Process object Close method that I called following CloseMainWindow. Close is supposed to clean up the Process object following a Kill or a CloseMainWindow as documented by Microsoft. It works OK on the desktop but on the device it appears to try to close the process associated with it whether it exists or not :( - hence the exception. Oddly, called after Kill on the device it doesn't error, only after CloseMainWindow :confused:
 
Top