Skip to content

[18.8.0] char* node::Buffer::Data(v8::Local<v8::Object> val) returns a NULL pointer when given a valid v8::Object #44554

Description

@gierschv

Version

18.8.0

Platform

macOS Monterey 12.4

Subsystem

No response

What steps will reproduce the bug?

Try to initialise a lame Encoder using this lib : https://github.com/FlatIO/node-lame (check Example : https://github.com/FlatIO/node-lame#example)

How often does it reproduce? Is there a required condition?

Everytime

What is the expected behavior?

node::Buffer::Data() returns a valid pointer when a valid v8::Object is provided.
Then, the lame Encoder is initialized without any issue.

What do you see instead?

node::Buffer::Data() returns a NULL pointer.
The lame encoder returns this error: “error setting prop “channels”: -1"

Additional information

This was working fine with node v18.7.0 and all the previous versions so this is very probably an issue with Node.
I did some investigation and found out that it was caused by a NULL pointer returned by node::Buffer::Data() when provided with a seemingly valid v8::Object
I tested the v8::Object with ->IsObject(), it returned true, and with ->IsNullOrUndefined() and it returned false;
The v8::Object (GFP) represents Lame global flags, and node::Buffer::Data is used to unwrap the pointer after sending it through a JS binding

Activity

  1. targos commented on Sep 7, 2022

    @targos
    Member
  2. bnoordhuis commented on Sep 8, 2022

    @bnoordhuis
    Member

    I suspect the problem is here: it calls Nan::NewBuffer() with length == 0.

    Maybe that worked before but it's basically saying "this is an empty buffer" and those don't have to point to anything.

  3. kvakil commented on Sep 9, 2022

    @kvakil
    Contributor

    Thanks @targos for the bisect. I've confirmed Ben's comment that this is an edge case with zero-length buffers: if you bump the "length" in WrapPointer from 0 to 1, then everything works. I am a little ambivalent about fixing the issue, but a codesearch did reveal several repos which are using this pattern, so I think we should just revert.

    A fix is available here; #44579

  4. github-actions commented on Jun 25, 2026

    @github-actions
    Contributor

    This issue has been marked as stale due to 210 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  5. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 25, 2026
  6. github-actions commented on Jul 26, 2026

    @github-actions
    Contributor

    This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
    If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions