(Bug): free(): invalid pointer

[splidje]

Make sure to follow our issue report guidelines

• I'm using the latest version of Natron (not required but recommended)
• I've restarted Natron and the issue persists
• I've run Natron via the command line and the issue persists
• I've followed the contributing guidelines to the best of my understanding
• My issue is not on the issue tracker or in a pull request already (go search for it and dig around a little bit!)
• This bug is reproducible

Natron version

Natron 2.5.0

Operating system

Ubuntu 25.04

System specs

RAM: 16GiB
CPU: AMD Ryzen™ 7 5800H
GPU: Radeon™ Graphics × 16

Did you install Natron using the official installer?

• Yes, I used the official installer
• No, I installed from a binary archive
• No, I compiled Natron from sources
• No, I installed Natron via another method

Custom installation path

~/Natron-2.5.0

What were you trying to do?

Create a Read node for an EXR (or any image/movie file).

What did you expect to happen? What happened instead?

Natron immediately crashed with:

free(): invalid pointer
Aborted (core dumped)

written out.

Step-by-step reproduction instructions

1. Start Natron
2. type "r"
3. Browse to file
4. Ok

Additional details

No response

[lazarus-gumbi]

Hi Guys, has anyone found a way to fix this issue, it is happening for me when trying to use the write node and the read node

[rodlie]

Need more info.

I just tested (on Intel CPU/GPU) Natron 2.5.0 binaries on Fedora 43 and Ubuntu 24.04/25.10 (live ISOs), works on both (Fedora required libxcrypt-compat, Ubuntu required libglu1-mesa, else worked out-of-the-box).

[msrst]

I am facing the same issue and could get a stack trace by compiling Natron 2.5.1-pre2 (commit 93c6837) with debugging symbols.
I am using Ubuntu 24.04.3 LTS.

Commands for compilation:

mkdir builds
docker run -it --rm --mount src="$(pwd)/builds",target=/home/builds_archive,type=bind natrongithub/natron-sdk:latest

Command to run it: catchsegv ./bin/Natron

I am attaching both the catchsegv stacktrace, as well as the gdb stacktrace, because gdb is able to provide line numbers for IO.ofx (IOSupport) which catchsegv did not achieve:

catchsegv_stacktrace.txt (also includes Natron's output logs)
gdb_stack_trace.txt

I also examined the config filename that is passed to OpenColorIO_v2_2::Config::CreateFromFile in GenericOCIO.cpp:1320 in gdb:

(gdb) frame 14
Downloading source file /home/tmp/openfx-io/IO/../IOSupport/GenericOCIO.cpp
#14 0x00007fff976ba202 in OFX::IO::GenericOCIO::describeInContextInput (desc=..., page=page@entry=0x2ad7b40, inputSpaceNameDefault=0x7fff977965b3 "scene_linear",                             
    inputSpaceLabel=inputSpaceLabel@entry=0x7fff977897d1 "File Colorspace") at ../IOSupport/GenericOCIO.cpp:1320
warning: 1320	../IOSupport/GenericOCIO.cpp: Aucun fichier ou dossier de ce nom
(gdb) info locals
file = 0x2addba5 "/media/tmpfs/natron2/Natron-RB-2.5-202511161625-93c6837-Linux-x86_64-debug-no-installer/Resources/OpenColorIO-Configs/blender/config.ocio"
locale = {oldLocale = 0xffffffffffffffff, currentLocale = 0x7ffff6201de0 <_nl_C_locobj>}
config = std::shared_ptr<const OpenColorIO_v2_2::Config> (empty) = {get() = 0x0}
inputSpaceName = <error reading variable: Cannot access memory at address 0x11>
outputSpaceName = <error reading variable: Cannot access memory at address 0xffffffffffffffe8>

Generally, OpenColorIO seems to be able to load the config.ocio file as the following test program compiles and runs:

#include "OpenColorIO/OpenColorIO.h"
namespace OCIO = OCIO_NAMESPACE;

// g++ main.cpp /media/tmpfs/natron2/Natron-RB-2.5-202511161625-93c6837-Linux-x86_64-debug-no-installer/lib/libOpenColorIO.so.2.2.1 -o main
// LD_LIBRARY_PATH=/media/tmpfs/natron2/Natron-RB-2.5-202511161625-93c6837-Linux-x86_64-debug-no-installer/lib ./main

int main()
{
    const char *file = "/media/tmpfs/natron2/Natron-RB-2.5-202511161625-93c6837-Linux-x86_64-debug-no-installer/Resources/OpenColorIO-Configs/blender/config.ocio";
    OCIO::ConstConfigRcPtr config;
    config = OCIO::Config::CreateFromFile(file);
}

I am unable to dig deeper at the moment due to lack of time but maybe @rodlie you can make some use of this.