Can anyone check?
dim n() as Text
dim p as new xojo.io.FolderItem( SpecialFolder.Documents.NativePath.ToText )
if p<>nil and p.Exists then
For Each f As xojo.io.FolderItem In p.Children
n.Append f.DisplayName
next
end if
dim t as Text = text.Join( n, EndOfLine.UNIX.ToText)
#Edit:
I had some crap in the original code. You should check for f=nil although I think it should not be nil.
Tested on Windows 10 64bit works just fine, both 32 and 64 bit version
maybe you check crash report?
or put some msgbox there to see which line crashes?
[quote=236274:@Christian Schmitz]maybe you check crash report?
or put some msgbox there to see which line crashes?[/quote]
I can’t set breaks as the app/debuggers crashes instantly after leaving the function. The original function is enclosed. R2015R3 works fine but R4 for some reasons not.
[code]using xojo.io
using xojo.core
try
dim p as new FolderItem( Glob.cfg.value(clsConfig.CFG_KEY_FILEPATH) )
if p<>nil and p.Exists then
dim fName as Text
dim pattern() as Text = Glob.filePattern.Split( “.”, 0 )
dim fileBeginning as Text = pattern(0)+"."+pattern(1)
dim fileEnding as Text = pattern(pattern.Ubound)
dim trueFile as Boolean
for each f as FolderItem in p.Children
trueFile = (f<>nil and f.Exists and not f.IsFolder)
if trueFile then
fName = f.DisplayName
trueFile = fName.BeginsWith( fileBeginning ) and fName.EndsWith( fileEnding )
if trueFile then
SimpleBrowser1.addItem ( f )
end if
end if
next
end if
catch iae as InvalidArgumentException
msgbox “Fehler: Dateipfad nicht vorhanden”
end try[/code]
CrashReport:
Process: My Application.debug [1501]
Path: /Users/USER/*/My Application.debug.app/Contents/MacOS/My Application.debug
Identifier: com.mycompany.myapp
Version: ??? (1.0.0.0.0)
Code Type: X86 (Native)
Parent Process: launchd [157]
User ID: 504
Date/Time: 2015-12-18 09:36:38.733 +0100
OS Version: Mac OS X 10.8.5 (12F45)
Report Version: 10
Interval Since Last Report: 14054943 sec
Crashes Since Last Report: 20
Per-App Interval Since Last Report: 778997 sec
Per-App Crashes Since Last Report: 1
Anonymous UUID: 15FB7A5B-9DAD-1B3C-95D1-1439CE21177C
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000200e8833
VM Regions Near 0x200e8833:
MALLOC_LARGE 000000000bf80000-000000000c11b000 [ 1644K] rw-/rwx SM=PRV
-->
__TEXT 000000008fe1a000-000000008fe4d000 [ 204K] r-x/rwx SM=COW /usr/lib/dyld
Application Specific Information:
objc_msgSend() selector name: release
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x940e2a87 objc_msgSend + 23
1 libobjc.A.dylib 0x940e5442 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 490
2 com.apple.CoreFoundation 0x97a25a63 _CFAutoreleasePoolPop + 51
3 com.apple.Foundation 0x957753fd -[NSAutoreleasePool drain] + 122
4 com.apple.AppKit 0x92e4e68a -[NSApplication run] + 1045
5 com.xojo.XojoFramework 0x00468fd9 0x2c4000 + 1724377
6 com.xojo.XojoFramework 0x004671ac RuntimeRun + 49
7 com.mycompany.myapp 0x00127e77 REALbasic._RuntimeRun + 34
8 com.mycompany.myapp 0x00237e52 _Main + 257
9 com.mycompany.myapp 0x0023614e main + 36
10 com.mycompany.myapp 0x002390a5 start + 53
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x99dcf9ae kevent + 10
1 libdispatch.dylib 0x9538bc71 _dispatch_mgr_invoke + 993
2 libdispatch.dylib 0x9538b7a9 _dispatch_mgr_thread + 53
Thread 2:
0 libsystem_kernel.dylib 0x99dcf0ee __workq_kernreturn + 10
1 libsystem_c.dylib 0x9a36b0ac _pthread_workq_return + 45
2 libsystem_c.dylib 0x9a36ae79 _pthread_wqthread + 448
3 libsystem_c.dylib 0x9a352daa start_wqthread + 30
Thread 3:
0 libsystem_kernel.dylib 0x99dcf0ee __workq_kernreturn + 10
1 libsystem_c.dylib 0x9a36b0ac _pthread_workq_return + 45
2 libsystem_c.dylib 0x9a36ae79 _pthread_wqthread + 448
3 libsystem_c.dylib 0x9a352daa start_wqthread + 30
Thread 4:
0 libsystem_kernel.dylib 0x99dcf0ee __workq_kernreturn + 10
1 libsystem_c.dylib 0x9a36b0ac _pthread_workq_return + 45
2 libsystem_c.dylib 0x9a36ae79 _pthread_wqthread + 448
3 libsystem_c.dylib 0x9a352daa start_wqthread + 30
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00e537e0 ebx: 0x95775391 ecx: 0x936a4eb0 edx: 0x200e8813
edi: 0x0104c028 esi: 0x0104c000 ebp: 0xbffffac8 esp: 0xbffff878
ss: 0x00000023 efl: 0x00010202 eip: 0x940e2a87 cs: 0x0000001b
ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f
cr2: 0x200e8833
Logical CPU: 0Sounds like an object is released too often, so maybe a bug in the framework.
Can you report it via Feedback with a sample project?
reported as case 41904.
Yes, seems like that. Thanks for submitting the fb case.
please add yourself there with a comment or test project.
Put it in your favorites or in your top cases.
Got bit by this one just today. The crash report didn’t help, at all, so I ended up figuring out the sequence to make it crash reliably and only stepping through code.
It’s…disappointing that the new framework isn’t more stable. More reasons to not use it for a while yet.
[quote=238190:@Bob Keeney]Got bit by this one just today. The crash report didn’t help, at all, so I ended up figuring out the sequence to make it crash reliably and only stepping through code.
It’s…disappointing that the new framework isn’t more stable. More reasons to not use it for a while yet.[/quote]
Yeah, that this bug slipped by is very unfortunate because the new framework’s directory iteration is much better for performance and minimizing disk IO. This is fixed for the next release and tests added to make sure it doesn’t break again.
Thanks Joe. This fix is really important for the reasons you mention and generally for the new framework.
That will be great…in the future release (hopefully we don’t have to wait until March). Until then we’re screwed and have to revert to the old framework.
Honestly, we are regretting trying to use the new framework in our projects. The little inconsistencies and bugs are not only annoying but cost me a lot in time and effort to track down.