Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NSData.dataWithBytesNoCopy_length_ is crashing #1107

Open
liamappelbe opened this issue Apr 29, 2024 · 4 comments
Open

NSData.dataWithBytesNoCopy_length_ is crashing #1107

liamappelbe opened this issue Apr 29, 2024 · 4 comments

Comments

@liamappelbe
Copy link
Contributor

liamappelbe commented Apr 29, 2024

ns_data_test.dart causes some sort of seg faults crash loop when using NSData.dataWithBytesNoCopy_length_. I'm switching to NSData.dataWithBytes_length_ for now, which fixes the crash but is slower. Logs.

I noticed the crash in #1100, but it predates that PR (that log is from a nightly run). I haven't been able to get GDB working on my macbook, so I'm not sure exactly where the crash is happening. From the logs it seems to be happening when the NSData is destroyed.

@brianquinlan
Copy link
Contributor

@dcharkes

NSData dataWithBytesNoCopy:length:freeWhenDone: takes ownership of a block of memory that was allocated with malloc.

Is the package:ffi malloc the (presumably) libc malloc that NSData expects?

@dcharkes
Copy link
Collaborator

dcharkes commented May 1, 2024

I haven't been able to get GDB working on my macbook

LLDB is the Mac variant.

Is the package:ffi malloc the (presumably) libc malloc that NSData expects?

final PosixMalloc posixMalloc =
stdlib.lookupFunction<PosixMallocNative, PosixMalloc>('malloc');

Yep, it's malloc in the current process.

@brianquinlan
Copy link
Contributor

brianquinlan commented May 1, 2024

I haven't been able to get GDB working on my macbook

LLDB is the Mac variant.

Is the package:ffi malloc the (presumably) libc malloc that NSData expects?

final PosixMalloc posixMalloc =
stdlib.lookupFunction<PosixMallocNative, PosixMalloc>('malloc');

Yep, it's malloc in the current process.

I'm not sure how this fits together. Presumably the malloc of the current process could mean tcmalloc or jemalloc, depending on how the application is linked? But I'd guess that NSData uses whatever the standard deallocator is? Or maybe not ;-)

Apple's documentation isn't very clear on this. I also notice that we don't use NSData dataWithBytesNoCopy:length:freeWhenDone: at Google at all.

I think that this code is probably OK how it is now. If people complain about the performance when using large blocks of memory, we could use initWithBytesNoCopy:length:deallocator:

@vaind
Copy link
Contributor

vaind commented Jul 2, 2024

Presumably the malloc of the current process could mean tcmalloc or jemalloc, depending on how the application is linked

From the docs:

A buffer containing data for the new object. If freeWhenDone is YES, bytes must point to a memory block allocated with malloc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Backlog
Development

No branches or pull requests

4 participants