Some advice on problems with MAC 64 bit native (Logic)


#1

Guys, please, I'm trying to figure out why the following code is crashing only with Logic MAC 64 bits version. EnergyXT 32 bits MAC works. And Windows both 32 and 64 bits works.

The code is trying to load a WusikSND file, 16 bits and 2 Channels (Stereo).

Sadly I don't have Logic to debug, only eXT and it works without problems. Is there any VST/AU free 64 bit native host I could use on the MAC?

I was wondering on the tHeader structure, if somehow is translating wrong for MAC 64 bit native. Another thing would be the way I'm using HeapBlock, but it works on Win 32/64 and MAC 32... so I'm not sure.

The code starts at line 146 of the file below.

http://github.com/Wusik4000/Wusik_4000_SDK/blob/master/Modules/Sound%20Generators/Sample%20Player/Source/WusikSND.cpp

Any advice would be much appreciated.

Thank you all in advance.


#2

And here's part of the error report I got from the Logic user. Two other users had the same problem but I forgot which host it was.

Process: Logic Pro X [892]
Path: /Applications/Logic Pro X.app/Contents/MacOS/Logic Pro X
Identifier: com.apple.logic10
Version: 10.0.6 (3130.20)
Build Info: MALogic-3130020000000000~1
App Item ID: 634148309
App External ID: 283213010
Code Type: X86-64 (Native)
Parent Process: launchd [163]
Responsible: Logic Pro X [892]
User ID: 501

PlugIn Path: /Applications/Wusik 4000 Data/*/Sample Player.dylib
PlugIn Identifier: Sample Player.dylib
PlugIn Version: ??? (0)

Date/Time: 2014-03-28 20:11:25.846 -0500
OS Version: Mac OS X 10.9.2 (13C64)
Report Version: 11
Anonymous UUID: 16C7B224-7C22-A557-9A8C-1640F806A329

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
terminating
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8b189866 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff8a0fc35c pthread_kill + 92
2 libsystem_c.dylib 0x00007fff885b2b1a abort + 125
3 libc++abi.dylib 0x00007fff8b13af31 abort_message + 257
4 libc++abi.dylib 0x00007fff8b160878 default_terminate_handler() + 46
5 libc++abi.dylib 0x00007fff8b15e1d1 std::__terminate(void (*)()) + 8
6 libc++abi.dylib 0x00007fff8b15e261 std::terminate() + 81
7 Sample Player.dylib 0x000000012276f680 juce::AudioSampleBuffer::AudioSampleBuffer(int, int) + 48
8 Sample Player.dylib 0x000000012275fe5a SamplePlayer::importWusikSND(juce::String) + 1834
9 Sample Player.dylib 0x00000001227678e5 SamplePlayer::importWaveform(juce::String) + 549
10 Sample Player.dylib 0x0000000122765e66 SamplePlayer::setSpecialData(W4kMod::SpecialDataType, void*, int) + 4454
11 com.wusik.Wusik4000 0x000000012158cace WModuleWindow::setEvent(W4kMod::MouseEvent::Type, juce::MouseEvent const&) + 606
12 com.wusik.Wusik4000 0x000000012166a780 juce::Component::internalMouseUp(juce::MouseInputSource, juce::Point, juce::Time, juce::ModifierKeys) + 864
13 com.wusik.Wusik4000 0x00000001216cdea3 juce::MouseInputSourceInternal::setButtons(juce::Point, juce::Time, juce::ModifierKeys) + 355
14 com.wusik.Wusik4000 0x00000001216bffc6 juce::MouseInputSourceInternal::handleEvent(juce::ComponentPeer&, juce::Point, juce::Time, juce::ModifierKeys) + 374
15 com.wusik.Wusik4000 0x00000001216b8713 juce::ComponentPeer::handleMouseEvent(int, juce::Point, juce::ModifierKeys, long long) + 195
16 com.wusik.Wusik4000 0x00000001216d1d63 juce::NSViewComponentPeer::sendMouseEvent(NSEvent*) + 291
17 com.wusik.Wusik4000 0x00000001216cfe86 juce::JuceNSViewClass::asyncMouseUp(objc_object*, objc_selector*, NSEvent*) + 118
18 com.apple.Foundation 0x00007fff84d9b13e __NSThreadPerformPerform + 229
19 com.apple.CoreFoundation 0x00007fff879c0731 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
20 com.apple.CoreFoundation 0x00007fff879b1ea2 __CFRunLoopDoSources0 + 242
21 com.apple.CoreFoundation 0x00007fff879b162f __CFRunLoopRun + 831
22 com.apple.CoreFoundation 0x00007fff879b10b5 CFRunLoopRunSpecific + 309
23 com.apple.HIToolbox 0x00007fff8508fa0d RunCurrentEventLoopInMode + 226
24 com.apple.HIToolbox 0x00007fff8508f685 ReceiveNextEventCommon + 173
25 com.apple.HIToolbox 0x00007fff8508f5bc _BlockUntilNextEventMatchingListInModeWithFilter + 65
26 com.apple.AppKit 0x00007fff8ec0e3de _DPSNextEvent + 1434
27 com.apple.AppKit 0x00007fff8ec0da2b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
28 com.apple.AppKit 0x00007fff8ec01b2c -[NSApplication run] + 553
29 com.apple.AppKit 0x00007fff8ebec913 NSApplicationMain + 940
30 com.apple.logic10 0x000000010b79a655 0x10b2de000 + 4965973
31 libdyld.dylib 0x00007fff8fcca5fd start + 1

#3

Well obviously a struct containing longs will be a completely different layout on 64 vs 32 bits. Don't know if that's your problem but if you're defining a cross-platform struct you must use types that have a known size, and define the packing explicitly.

Some nasty coding habits in there, William! You need to get your head around RAII - deleteAndZero is just not how smart people manage their objects. And there's a lot of D.R.Ying that could be done. Not to mention basic security things like checking that your read() calls actually succeeded before working with possibly uninitialised data (!). And replace those tab characters with spaces (yuck!)


#4

Thanks Jules. The only thing I don't know about is explicit packing, so I have to check that. Well, no idea on what you are talking about related to Tabs, as MSVC is doing all this on its own, but I will check things out when possible.

Thanks again! :-)


#5

You can easily change the default tabs usage to spaces here (at least in VS2010):

Tools --> Options --> Text Editor --> C/C++ --> Tabs

Best is probably: Smart, tab size/indent size = 4, and insert spaces.