Napkin fails to launch, incorrect checksum, abort trap 6


#1

Hi,

my Napkin is no longer launching.
It says it’s looking for bin/Clang-x86_64-Debug/config.json, then fails with the following messages:

napkin(9057,0x1148b95c0) malloc: Incorrect checksum for freed object 0x7f8ab990c068: probably modified after being freed.
Corrupt value: 0xd00000003f800000
napkin(9057,0x1148b95c0) malloc: *** set a breakpoint in malloc_error_break to debug
Abort trap: 6

After some refactoring of components in a user module it started behaving weird; it was showing the new properties (I renamed some and changed their types), but kept also showing the old ones, and the values were linked to each other between the old and new version of each property.
I figured the module build must have gotten corrupted, so I cleaned it but to no avail.
I have since stripped down both the user module and the project using it and have regenerated and rebuilt them both, but Napkin will still not start up.

Any help would be greatly appreciated, as I’m blocked now; my app_strructure.json is too big to reliably edit by hand…


#2

I’ve tested the exact same project on another Mac, and Napkin launches just fine - no sign of the above error.

But this doesn’t exactly help to find out what is wrong, or how to fix it…


#3

Looking further back in the log, I see three .dylib’s not being found:

[warn] Failed to load module /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib: dlopen(/Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib, 1): Library not loaded: @rpath/libmod_napapp.dylib
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib
  Reason: image not found
[warn] Failed to load module /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib: dlopen(/Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib, 1): Library not loaded: @rpath/liboscpack.1.1.0.dylib
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib
  Reason: image not found
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napetherdream/lib/Debug/libmod_napetherdream.dylib
  Reason: image not found

#4

Note that I am running OSX 10.14 (Mojave) and that Napkin has been running without a hitch until now.


#5

Well, this makes it difficult to debug. Could be related to a caching issue but as far as i am aware Napkin doesn’t cache anything. Any ideas @bas?


#6

That’s what I figured as well, and that’s why this is so strange. I guess I can try to redownload NAP and move it all into the fresh install.

Napkin is copied when you build, correct? But regardless of which project you open it from, it always opens the last file it had open. So where is that information stored?


#7

Napkin uses a settings file to reopen the last file (and several other user settings such as window geometry, etc).

NAP core (which is used by Napkin) decides which modules are being loaded, just like the run-time, it’s not stored in the settings.
I’m a little rusty on how it decides where to load the modules from.

Can you post the full log?

Some details on the settings file, just in case:

The OS kind of decides where that file goes atm:

On Mojave, I’m finding this file here:
/Users/USERNAME/Library/Preferences/com.naivisoftware.Napkin.plist

On Linux, this file should be in a folder like:
/home/USERNAME/.config/NaiviSoftware/Napkin.conf

I just committed a change on master that will log the location of this file on startup.


#8

Ok, after removing the plist file Napkin started up normally, but when I opened the project’s JSON it crashed with the full log below. After removing the plist again it does so as well (so no normal startup first).

Here’s the current log, which is different from what it was. No more checksum and malloc errors, just unable to find dylibs:

[debug] Loaded module mod_napartnet v0.2.0
[warn] Failed to load module /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib: dlopen(/Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib, 1): Library not loaded: @rpath/libmod_napapp.dylib
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib
  Reason: image not found
[debug] Loaded module mod_napmath v0.2.0
[debug] Loaded module mod_napinput v0.2.0
[warn] Failed to load module /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib: dlopen(/Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib, 1): Library not loaded: @rpath/liboscpack.1.1.0.dylib
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib
  Reason: image not found
[debug] Loaded module mod_napapp v0.2.0
[debug] Loaded module mod_napvideo v0.2.0
[warn] Failed to load module /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napetherdream/lib/Debug/libmod_napetherdream.dylib: dlopen(/Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napetherdream/lib/Debug/libmod_napetherdream.dylib, 1): Library not loaded: @rpath/libEtherDream.dylib
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napetherdream/lib/Debug/libmod_napetherdream.dylib
  Reason: image not found
[debug] Loaded module mod_napsvg v0.2.0
[debug] Loaded module mod_napmidi v0.2.0
[debug] Loaded module mod_naprender v0.2.0
[debug] Loaded module mod_napfont v0.2.0
[debug] Loaded module mod_napscene v0.2.0
[debug] Loaded module mod_napsdlinput v0.2.0
[debug] Loaded module mod_nappython v0.2.0
[debug] Loaded module mod_napaudio v0.2.0
[debug] Loaded module mod_napcameracontrol v0.2.0
[debug] Loaded module mod_napyoctopuce v0.2.0
[debug] Loaded module mod_lighting v0.1.0
[debug] Loaded module mod_j12grandsalon v0.1.0
[debug] Loaded module mod_vfx v0.1.0
[debug] Looking for '/Users/ralph.kok/Projects/NAP-0.2.3-macOS/projects/j12-grand-salon/bin/Clang-x86_64-Debug/config.json'...
Segmentation fault: 11```

#9

Oh, so it doesn’t give the checksum and malloc errors at first startup, but after that on subsequent startups it does. Full log below:

[debug] Logging to file: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/projects/j12-grand-salon/bin/Clang-x86_64-Debug/log/napkin_2019-03-22_08-40-35_463.log
[fine] Loading theme: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/projects/j12-grand-salon/bin/Clang-x86_64-Debug/resources/themes/gray/theme.json
[fine] Loading theme: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/projects/j12-grand-salon/bin/Clang-x86_64-Debug/resources/themes/napkin/theme.json
[fine] Loading theme: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/projects/j12-grand-salon/bin/Clang-x86_64-Debug/resources/themes/native/theme.json
[warn] Settings file not found: 
[fine] Setting theme: Native
Empty filename passed to function
[info] Loading 'file:///Users/ralph.kok/Projects/NAP-0.2.3-macOS/projects/j12-grand-salon/data/app_structure.json'
[debug] Loaded module mod_napartnet v0.2.0
[warn] Failed to load module /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib: dlopen(/Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib, 1): Library not loaded: @rpath/libmod_napapp.dylib
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napimgui/lib/Debug/libmod_napimgui.dylib
  Reason: image not found
[debug] Loaded module mod_napmath v0.2.0
[debug] Loaded module mod_napinput v0.2.0
[warn] Failed to load module /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib: dlopen(/Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib, 1): Library not loaded: @rpath/liboscpack.1.1.0.dylib
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_naposc/lib/Debug/libmod_naposc.dylib
  Reason: image not found
[debug] Loaded module mod_napapp v0.2.0
[debug] Loaded module mod_napvideo v0.2.0
[warn] Failed to load module /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napetherdream/lib/Debug/libmod_napetherdream.dylib: dlopen(/Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napetherdream/lib/Debug/libmod_napetherdream.dylib, 1): Library not loaded: @rpath/libEtherDream.dylib
  Referenced from: /Users/ralph.kok/Projects/NAP-0.2.3-macOS/modules/mod_napetherdream/lib/Debug/libmod_napetherdream.dylib
  Reason: image not found
[debug] Loaded module mod_napsvg v0.2.0
[debug] Loaded module mod_napmidi v0.2.0
[debug] Loaded module mod_naprender v0.2.0
[debug] Loaded module mod_napfont v0.2.0
[debug] Loaded module mod_napscene v0.2.0
[debug] Loaded module mod_napsdlinput v0.2.0
[debug] Loaded module mod_nappython v0.2.0
[debug] Loaded module mod_napaudio v0.2.0
[debug] Loaded module mod_napcameracontrol v0.2.0
[debug] Loaded module mod_napyoctopuce v0.2.0
[debug] Loaded module mod_lighting v0.1.0
[debug] Loaded module mod_j12grandsalon v0.1.0
[debug] Loaded module mod_vfx v0.1.0
[debug] Looking for '/Users/ralph.kok/Projects/NAP-0.2.3-macOS/projects/j12-grand-salon/bin/Clang-x86_64-Debug/config.json'...
napkin(12794,0x1170d95c0) malloc: Incorrect checksum for freed object 0x7ff5ad4d44a8: probably modified after being freed.
Corrupt value: 0x400000003f000000
napkin(12794,0x1170d95c0) malloc: *** set a breakpoint in malloc_error_break to debug
Abort trap: 6

#10

There seems to be something wrong with napkin and resolving libraries. Ties into the problem Stephen was mentioning in another thread. I can’t provide an instant solution as I don’t have your project structure and can’t look into the way the project is setup or the code associated with your project. Probably best if @stijnvanbeek debugs it with you on location.


#11

The new build over here resolves these three module loading issues for Napkin on macOS. I’m not sure if those are the cause of your issue, but the new build is a good starting point.

The changes will be in the next framework release.


#12

Thanks Chris, Napkin does indeed run for me with that build.

I noticed that this build has a change in RenderTarget (instead of setting textures you now need to switch textures, which is the result of a change Coen made based on a request from me).
I hadn’t gotten around to checking this change out yet, but am now running into a situation where after creating textures at runtime, trying to set them on a runtime created RenderTarget results in a bad access error.
Inspecting the values doesn’t reveal anything special (e.g. no nullptr values), so I’m wondering if texture and rendertarget instantiation and initialization now has different requirements perhaps? Note that I’m asking b/c what I’m doing worked fine before I tried it in this build.

Here is my code, which is executed at component instance init time:

        mRenderTextureColor = createTexture(RenderTexture2D::EFormat::RGB8, error);
        if (!mRenderTextureColor->init(error)) {
            error.fail("unable to create color texture");
            return false;
        }
        
        mRenderTextureDepth = createTexture(RenderTexture2D::EFormat::Depth, error);
        if (!mRenderTextureDepth->init(error)) {
            error.fail("unable to create depth texture");
            return false;
        }
        
        mRenderTarget = std::make_unique<RenderTarget>();
        if (!mRenderTarget->switchColorTexture(*mRenderTextureColor, error)) {
            error.fail("Unable to switch color texture on RenderTarget");
            return false;
        }
        if (!mRenderTarget->switchDepthTexture(*mRenderTextureDepth, error)) {
            error.fail("Unable to switch depth texture on RenderTarget");
            return false;
        }
        if (!mRenderTarget->init(error)) {
            error.fail("unable to init render target");
            return false;
        }

and the createTexture method:

    std::unique_ptr<RenderTexture2D> SkyComponentInstance::createTexture(RenderTexture2D::EFormat format, utility::ErrorState& error) {
        std::unique_ptr<RenderTexture2D> render_tex = std::make_unique<RenderTexture2D>();
        render_tex->mWidth = 256;
        render_tex->mHeight = 256;
        render_tex->mFormat = format;
        render_tex->mUsage = opengl::ETextureUsage::DynamicRead;
        render_tex->mParameters.mMinFilter = EFilterMode::Linear;
        render_tex->mParameters.mMaxFilter = EFilterMode::Linear;
        render_tex->mParameters.mWrapVertical = EWrapMode::ClampToEdge;
        render_tex->mParameters.mWrapHorizontal = EWrapMode::ClampToEdge;
        render_tex->mParameters.mMaxLodLevel = 20;
        return render_tex;
    }

OSC module won't add anything to Napkin
#13

Yes you’re right that change has been included. Maybe I can roll you a build without this change in if that’s preferred?

Otherwise @cklosters might be able to help with your render target issue.


#14

@ralphkok Here’s a build with all other fixes but with the render target excluded, in case it’s useful.


OSC module won't add anything to Napkin
#15

Hi Ralph,

That is odd, the code related to the RenderTexture itself did not change, not being able to create it doesn’t seem to have anything to do with the change I made. That was related to the render target, ie: being able to switch the render texture at runtime.


#16

Ok, I will see if it helps to not create the textures and render target in code, but rather as resources via Napkin


#17

I figured it out, and it makes total sense.
I was calling RenderTarget.switchColorTexture() before RenderTarget.init(). Instead, I now just set the texture directly in the RenderTarget's member variable, then init it. Works like a charm.


#18

@chris Any chance of getting a Linux version of this, too? I need to run our project on a Linux machine and of course the compilation fails now because of this change.


#19

Hey @steveb, yep I can make that happen :slight_smile: Am I right in thinking that the render target changes can now be left in?


#20

Yes, that would be fine to leave those changes in. That’s the exact part we’re trying to get to work now on the Linux build.