Troubleshooting

A warning strip at the top of the Study Editor with a Re-check button. As of 1.0.144 the compiler ships inside the app, so this only appears on a broken or incomplete install.

• Reinstall the app, then click Re-check.
• If you are running a dev tree or a custom layout, point SHARPNEL_STUDY_TOOLCHAIN at an LLVM/Clang MinGW folder (either the toolchain root containing bin/, or the bin directory itself) and Re-check.

The compiler could not find the SDK include directory. The app ships sharpnel_study_sdk.h in an sdk folder next to the executable. If it is missing, reinstall — or set SHARPNEL_SDK_DIR to the folder that holds the header.

Ordinary C++ diagnostics from the bundled Clang — file, line, and message. Read the first error; later ones are often cascades. Common causes:

• Unknown identifier / include: a study may include only sharpnel_study_sdk.h from Sharpnel. Standard-library headers (<new>, <cmath>, <string.h>) are fine.
• Missing or misnamed export: the required sharpnel_study_v1_* functions must be spelled exactly and wrapped in extern "C" with SHARPNEL_STUDY_API. A missing required symbol rejects the whole plugin.
• Wrong signature: match the header exactly — e.g. compute() takes (void*, const SnSeries*, uint64_t, const SnInput*, int, SnSink*, const SnSinkApi*).

The DLL compiled but failed validation at load — usually an ABI mismatch (wrong abi_version() return, or a required export the linker dropped). Confirm abi_version() returns SHARPNEL_STUDY_ABI_VERSION and that all six required exports are present and exported.

• All warmup: if your loop writes SN_NOVALUE until period bars exist and the chart has fewer bars than that, there is nothing to draw yet. Load more history or lower the input.
• Buffer not obtained: if subgraph() returned a null ptr you must return early — writing through it does nothing. Check for if (!buf.ptr) return;.
• Wrong pane: an oscillator declared as SN_TARGET_OVERLAY may be drawing far off the visible price scale. Use SN_TARGET_SUBPANE for anything that isn't in price units.

The plugin faulted or wrote out of bounds, so the host fault-disabled it for the rest of the session — by design, so a bad build never crashes the terminal. Fix the cause and re-compile:

• Out-of-bounds write: only write indices [0, len) of a subgraph buffer. Bound your loop by buf.len (the examples do min(s->count, buf.len)). Writing past the end trips the host's canary.
• Escaping exception: no exception may cross the boundary. Wrap the body of compute() in try / catch(...), and guard against divide-by-zero, null dereferences, and bad indices.
• Retained pointers: the sink, api, series, and every const char* are valid only inside the call that supplied them. Never store them for later.

Safe. Each build gets a session-unique DLL name, so a re-compile hot-loads a fresh copy while the previously loaded one stays mapped — there is no locked-file error to work around. A staged .dll.pending copy is promoted to the canonical name at your next startup, so the latest build is what auto-loads next launch.

A DLL you placed in the studies folder yourself — rather than built in the editor — is quarantined until you approve it in Custom Studies › Manage Plugins…. Its code is never run until you trust it. Studies the editor builds from your own source are trusted automatically.

The v1 ABI is frozen and grows only additively, so a v1 study keeps loading across updates. If you ever see a version refusal, the study was built against a different ABI major — rebuild it against the current sharpnel_study_sdk.h that ships with your app.