SyntaxBomb - Indie Coders

* This thread has been solved *

----------------------------------------------------

I've stumbled across a weird issue.  It seems my latest project only runs inside the IDE and not stand-alone.

It compiles just fine release/debug, but attempting to run it outside of the IDE (via EXE and .APP) will just force close it.  Hmm.

Any ideas?  Using latest NG.

Can you recreate it in a small example or share your project?

Quote from: therevills on April 16, 2019, 09:59:05
Can you recreate it in a small example or share your project?

I don't know what causes it on that particular project; Secluding it wouldn't be easy.  It's commissioned / closed source work, so i cannot publish the source.   This thread might not go anywhere because of that.

Multiple Questions:

1.) Does it only happen to this particular project?
2.) Does it happen only on your OS?
3.) Which OS do you build for (and 32 or 64bit)
4.) Do you do a "console" or a "GUI" build?
5.) Does it happen too if you switch from "console" to "GUI" (or vice versa)?
6.) Does it crash if you execute it from within a terminal?
7.) What version of BMX-NG are you using? Latest "package" or fully updated modules+binaries?

I ask this as eg. with SDL and Mac + "console build" the event handling goes wonky.


What could you do to narrow it down?
Build the thing in "Debug" mode and enable in MaxIDE (developer options) that you want to have "GDB" informations created. This means that it stores the original BlitzMax-source-information along the generate c-code so that other debuggers might be able to show the right source position instead of the position in the generated C code.
Ok, so once you build that debug binary you could run this binary via "GDB" (terminal: "gdb -r MyBinary"). Once it crashes during execution you coult enter "bt" to see a backtrace of the function calls - which will show where it is crashing and from where the code line originally was called.


bye
Ron

To compliment what Derron is suggesting...

Accessing a null object would be the usual cause of an exe just exiting without notice.

Quote from: col on April 16, 2019, 14:11:25
Accessing a null object would be the usual cause of an exe just exiting without notice.

> It compiles just fine release/debug, but attempting to run it outside of the IDE (via EXE and .APP) will just force close it.  Hmm.


I think a null access would crash in both cases then. If it would crash in both sides and debugger does not catch it, then it is possibly something in the .c files (so beyond the blitzmax debugger's scope).


bye
Ron

Quotethen it is possibly something in the .c files (so beyond the blitzmax debugger's scope).

That's very true

Quote from: Derron on April 16, 2019, 11:08:53
Multiple Questions:

....

1.) Yes
2.) No | Win10 LTSC x64 / WinXP sp3 x86
3.) ^, main Win10 LTSC x64 |  I also target 486/pentium3
4.) GUI
5.) Same for both
6.) Yes
7.) Latest package w/ latest module repos

Quote from: col on April 16, 2019, 14:11:25
To compliment what Derron is suggesting...

Accessing a null object would be the usual cause of an exe just exiting without notice.

I also use  "if variable" to handle null and if "object.name" to check if a specific type is loaded before usage.  I handle both accordingly, so it's not that.

The issue has been resolved, however.  I removed a feature the client didn't need, that involved Derron's scandir.  Once it was commented out, it runs stand-alone on any processor that supports threading. RIP Pentium 3 support.

Did you use a whole custom function by me or did you write your own stuff around the scandir function of BlitzMax?
Maybe my code has some error or so.

Bye
Ron

Quote from: Derron on April 17, 2019, 02:10:28
Did you use a whole custom function by me or did you write your own stuff around the scandir function of BlitzMax?
Maybe my code has some error or so.

Bye
Ron

Yes, i used your work, whole.  I didn't write anything for that.

Would you mind narrowing down the bug?
So you used the whole .bmx file ? How did you setup the TDirectoryTree and how did you call methods?


Maybe we could narrow it down?


Bye
Ron

So open up the file and there is this method here:


'scans all files and directories within the given base
'directory.
'if no file ending is added until scanning, all files
'will get added
Method ScanDir:Int( directory:String="", sortResults:int=True )
If directory = "" Then directory = baseDirectory
?bmxng
Local dirHandle:Byte Ptr = ReadDir(directory)
?not bmxng
Local dirHandle:Int = ReadDir(directory)
?
If Not dirHandle Then Return False


Local file:String
Local uri:String
Repeat
file = NextFile(dirHandle)
If file = "" Then Exit
'skip chgDir-entries
If file = ".." Or file = "." Then Continue

uri = directory + "/" + file

Select FileType(uri)
Case 1
'skip forbidden file endings
If _excludeFileEndings.Contains( ExtractExt(file).toLower() ) Then Continue
'skip files with non-enabled file endings
If _includeFileEndings.Count() > 0 and Not _includeFileEndings.Contains( ExtractExt(file).toLower() ) And Not _includeFileEndings.Contains("*") Then Continue

'skip forbidden file names
If _excludeFileNames.Contains( StripAll(file).toLower() ) Then Continue
'skip files with non-enabled file names
If _includeFileNames.Count() > 0 and Not _includeFileNames.Contains( StripAll(file).toLower() ) And Not _includeFileNames.Contains("*") Then Continue

AddFile( GetURI(uri) )
Case 2
'skip forbidden directories
If _excludeDirectoryNames.Contains( file.toLower() ) Then Continue
'skip forbidden paths
If _excludeDirectoryNames.Contains( uri.toLower() ) Then Continue
'skip directories with non-enabled directory names
If Not _includeDirectoryNames.Contains( file.toLower() ) And Not _includeDirectoryNames.Contains("*") Then Continue
'skip paths with non-enabled directory names
If Not _includeDirectoryNames.Contains( uri.toLower() ) And Not _includeDirectoryNames.Contains("*") Then Continue

AddDirectory( GetURI(uri) )
ScanDir(uri)
End Select
Forever

CloseDir(dirHandle)

if sortResults
directories.Sort(True)
filePaths.Sort(True)
endif

Return True
End Method

you could add some "print" every here and there - and during execution you will see which one is the last output line. Maybe it loops forever in the repeat (eg it only receives "." and ".." as file and never "". So the loop would run forever ("stalled") ?

Means next to other prints you should do this:

Repeat
file = NextFile(dirHandle)
'add this line here
print "directory: ~q" + directory + "~q   file: ~q" + file +"~q"


Maybe even the fileTypes get read wrong (or my logic does something wonky). So as said: add some prints here and there and let's see what it does.


bye
Ron

Quote from: Derron on April 17, 2019, 05:50:53
...

Ron, Scandir seems to be fine now.  I had some time free, so i uncommented it and built it.   It compiled.

I hadn't changed anything, since my Win23 release.  So, i don't know what to say.

No, i didn't upgrade the BCC or BMK either.   Probably a MinGW mishap.

Thanks for the heads up ... checked my code meanwhile too and thought it might have failed on Mac with empty directories or so but ... glad it works now.


bye
Ron