malloc: *** error for object 0x100000000: pointer being freed was not allocated #171

guymguym · 2015-03-23T23:47:56Z

hi

I see this issue like discussed in #170

node(46307,0x104516000) malloc: *** error for object 0x100000000: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

though I use a different test -
https://gist.github.com/guymguym/728bf41ab38466ccca4f (see usage in gist comment).
when the two peers are chrome/firefox it works well (though with 100% cpu for just ~5 MB/s on Macbook Air 🐌 ).
but any wrtc client fails pretty quickly.

this occurs on OSX 10.10.2 with latest wrtc version which is 0.0.49 in npm (which is not the same as the github release numbers ?!).

The text was updated successfully, but these errors were encountered:

guymguym · 2015-03-27T22:38:56Z

@modeswitch Hi,
This issue is quite the killer, as it fails every time.
Do you see it reproducing too?
Does pull-request #170 offers any fix around these memory allocation issues?
Any idea?
Thanks!

modeswitch · 2015-03-27T23:44:54Z

@guymguym I'm having a look now.

guymguym · 2015-03-27T23:56:13Z

👍

modeswitch · 2015-03-28T00:06:30Z

@guymguym I'm seeing a crash. I'm also seeing that only some of the buffers are arriving in the browser.

guymguym · 2015-03-28T00:08:44Z

by "some buffers are arriving" do you mean that when you run browser vs. browser you see "BAD SEQUENCE" prints? because the code tries to check that all packets arrive in order...
or you mean browser vs. node?

modeswitch · 2015-03-28T00:11:36Z

No, I mean only some of the buffers are printed to the console. I'm using the modified bridge from #170.

guymguym · 2015-03-28T00:35:10Z

I didn't follow which prints you mean, so not sure if I can assist.

BTW you maintain a copy of webrtc repo in libwebrtc. Doesn't it make it hard to sync with changes and avoid collisions? Wasn't it possible to use the original repo and just make a custom build and bridge for node?

modeswitch · 2015-03-28T00:46:58Z

The buffers are printed to the console as they are received.

I was originally using upstream libjingle, but it has many dependencies and is therefore difficult to build for many people. The fork I have is missing the implementation for media streams, which dramatically reduces the number of external dependencies.

guymguym · 2015-03-30T04:34:56Z

Hey @modeswitch just wondering if you got any lead on that?

I would be happy to help investigating if you can share your thoughts and point out suspected areas, because I am not yet familiar with webrtc's inner implementation and specific versions status (pending critical issues and such).

Thanks!

guymguym · 2015-04-01T00:17:20Z

@modeswitch - I wonder, am I the only one trying to use data-channels to send lots of data?
This issue occurs immediately when sending large amounts of data, so it's hard to believe that anyone else is doing that successfully...

rosskukulinski · 2015-04-01T00:31:11Z

@guymguym I'm hoping to take a peak at this issue later this week

guymguym · 2015-04-01T00:33:30Z

@rosskukulinski 👍 Great. I'm digging my way as well.

guymguym · 2015-04-01T01:42:05Z

submitted pull request #182 with a simple local reproduction of the error

rosskukulinski · 2015-04-01T21:41:14Z

so I'm in debug land looking into a few issues. By all means, node-webrtc shouldn't crash. but, it seems you're sending too large of a packet:

Error(sctpdataengine.cc:895): SctpDataMediaChannel->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU.
Error(sctpdataengine.cc:573): ERROR:SctpDataMediaChannel->SendData(...):  usrsctp_sendv:  : [0x00000016] Invalid argument
Error(datachannel.cc:512): Closing the DataChannel due to a failure to send data, send_result = 1

guymguym · 2015-04-02T00:40:22Z

@rosskukulinski The code in #182 currently sends 16K packets as I saw recommended, and that works perfectly in chrome and firefox. I tried changing the sends to various smaller sizes and it always fails, even for packets of 8 bytes! you can also change the PACKET_SIZE in the code, but it's not affecting the original error (pointer being freed was not allocated).
how do you make webrtc print these errors to console?

I found this error here:
https://github.com/js-platform/libwebrtc/blob/master/talk/media/sctp/sctpdataengine.cc#L894
and kSctpMtu = 1200 is compared with the buffer size.
so there might be some bug or intentional buffering system before the buffer arrives from js to sctp code.

rosskukulinski · 2015-04-02T00:42:27Z

@guymguym - Yes, I found it to crash no matter what as well. More just something I noticed.

The debug messages are by building the node-webrtc with debug symbols, then run node with --debug.

guymguym · 2015-04-02T01:04:21Z

@rosskukulinski
I had a prebuilt binary at first and then I did npm install --build-from-source --debug and debug binary was created, but when I run it keeps failing for me trying to find Release binary, any idea what am I doing wrong:

~/code/node-webrtc $ node test/bwtest.js --debug

module.js:340
    throw err;
          ^
Error: Cannot find module '/Users/self/code/node-webrtc/build/wrtc/v0.0.51/Release/node-v11-darwin-x64/wrtc.node'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/Users/self/code/node-webrtc/lib/peerconnection.js:5:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

guymguym · 2015-04-02T01:36:07Z

regarding the MTU I found this -
https://groups.google.com/forum/#!msg/discuss-webrtc/XIdVkoS4-Cs/YuA0ZvwCgXoJ
https://code.google.com/p/webrtc/issues/detail?id=3657
this was supposed to be solved, but maybe in node-webrtc requires something as well..

rosskukulinski · 2015-04-02T01:46:20Z

oh -- regarding that resolveFilename error -- tweak package.json path to use 'Debug' rather than ''.

rosskukulinski · 2015-04-02T01:51:44Z

good find on the error -- looks like we should update libwrtc. For now, could possibly patch: https://github.com/js-platform/libwebrtc/blob/master/talk/media/sctp/sctpdataengine.cc

guymguym · 2015-04-02T01:59:32Z

actually it seems like it's already patched - but it doesn't help
https://code.google.com/p/webrtc/source/detail?r=6829
js-platform/libwebrtc@624a504

rosskukulinski · 2015-04-02T02:04:11Z

@guymguym notice the last comment:

oh - i see what happened. Apparently kPathMtu (in sctpdataengine.cc) was changed from 1280 to 1200. The problem is that 1260 is the magical number thats the default in SCTP so it was working in the previous versions. Setting it back to 1280 to silence the log atleast :)

The kSctpMtu = 1200; in libwebrtc

All that said, I'm not sure this is related to the crash

guymguym · 2015-04-02T02:09:50Z

@rosskukulinski That's right, I changed to 1280 and the errors were gone. probably unrelated.

guymguym · 2015-04-02T09:54:13Z

@rosskukulinski @modeswitch

I'm trying to understand the memory handling of the buffers in this webrtc code and not yet sure what's going on.

I used valgrind and saw multiple issues like I copied below.

from what I understand in the code in SendQueuedDataMessages (see my ** marks) the front buffer is attempted but might not be able to send, and in this case the code breaks from the loop without popping the buffer from the send queue, but the scoped ptr will still be in effect and delete it. am I missing something about this memory handling?

==5203== Invalid read of size 1
==5203==    at 0x10A418BED: webrtc::DataChannel::SendDataMessage(webrtc::DataBuffer const&, bool) (datachannel.cc:492)
==5203==    by 0x10A41A122: webrtc::DataChannel::SendQueuedDataMessages() (datachannel.cc:466)
==5203==    by 0x10A419304: webrtc::DataChannel::OnChannelReady(bool) (datachannel.cc:378)
==5203==    by 0x10A4AF6DD: sigslot::_connection1<webrtc::DataChannel, bool, sigslot::single_threaded>::emit(bool) (sigslot.h:1853)
==5203==    by 0x10A4D1CCF: sigslot::signal1<bool, sigslot::single_threaded>::operator()(bool) (sigslot.h:2347)
==5203==    by 0x10A4CEBC6: cricket::DataChannel::OnMessage(rtc::Message*) (channel.cc:1431)
==5203==    by 0x10A681FA7: rtc::MessageQueue::Dispatch(rtc::Message*) (messagequeue.cc:381)
==5203==    by 0x10A6C74E3: rtc::Thread::ProcessMessages(int) (thread.cc:564)
==5203==    by 0x10A6C73E7: rtc::Thread::Run() (thread.cc:404)
==5203==    by 0x10A6C70C0: rtc::Thread::PreRun(void*) (thread.cc:396)
==5203==    by 0x103836267: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==5203==    by 0x1038361E4: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==5203==  Address 0x1083a7358 is 24 bytes inside a block of size 32 free'd
==5203==    at 0x100AD094F: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==5203==    by 0x10A41D2E3: rtc::DefaultDeleter<webrtc::DataBuffer>::operator()(webrtc::DataBuffer*) const (scoped_ptr.h:138)
==5203==    by 0x10A41D271: rtc::internal::scoped_ptr_impl<webrtc::DataBuffer, rtc::DefaultDeleter<webrtc::DataBuffer> >::~scoped_ptr_impl() (scoped_ptr.h:214)
==5203==    by 0x10A41D202: rtc::internal::scoped_ptr_impl<webrtc::DataBuffer, rtc::DefaultDeleter<webrtc::DataBuffer> >::~scoped_ptr_impl() (scoped_ptr.h:210)
==5203==    by 0x10A41D1B2: rtc::scoped_ptr<webrtc::DataBuffer, rtc::DefaultDeleter<webrtc::DataBuffer> >::~scoped_ptr() (scoped_ptr.h:441)
==5203==    by 0x10A41A922: rtc::scoped_ptr<webrtc::DataBuffer, rtc::DefaultDeleter<webrtc::DataBuffer> >::~scoped_ptr() (scoped_ptr.h:441)
==5203==    by 0x10A41A158: webrtc::DataChannel::SendQueuedDataMessages() (datachannel.cc:470)
==5203==    by 0x10A419304: webrtc::DataChannel::OnChannelReady(bool) (datachannel.cc:378)
==5203==    by 0x10A4AF6DD: sigslot::_connection1<webrtc::DataChannel, bool, sigslot::single_threaded>::emit(bool) (sigslot.h:1853)
==5203==    by 0x10A4D1CCF: sigslot::signal1<bool, sigslot::single_threaded>::operator()(bool) (sigslot.h:2347)
==5203==    by 0x10A4CEBC6: cricket::DataChannel::OnMessage(rtc::Message*) (channel.cc:1431)
==5203==    by 0x10A681FA7: rtc::MessageQueue::Dispatch(rtc::Message*) (messagequeue.cc:381)

void DataChannel::SendQueuedDataMessages() {
  ASSERT(was_ever_writable_ && state_ == kOpen);

  while (!queued_send_data_.Empty()) {
    rtc::scoped_ptr<DataBuffer> buffer(queued_send_data_.Front());
**    if (!SendDataMessage(*buffer, false)) {
**      break;
**    }
    queued_send_data_.Pop();
  }
}

bool DataChannel::SendDataMessage(const DataBuffer& buffer,
                                  bool queue_if_blocked) {
  cricket::SendDataParams send_params;

...

  cricket::SendDataResult send_result = cricket::SDR_SUCCESS;
  bool success = provider_->SendData(send_params, buffer.data, &send_result);

  if (success) {
    return true;
  }

  if (data_channel_type_ != cricket::DCT_SCTP) {
    return false;
  }

  if (send_result == cricket::SDR_BLOCK) {
    if (!queue_if_blocked || QueueSendDataMessage(buffer)) {
      return false;
    }
  }
  // Close the channel if the error is not SDR_BLOCK, or if queuing the
  // message failed.
  LOG(LS_ERROR) << "Closing the DataChannel due to a failure to send data, "
                << "send_result = " << send_result;
  Close();

  return false;
}

bool DataChannel::QueueSendDataMessage(const DataBuffer& buffer) {
  if (queued_send_data_.byte_count() >= kMaxQueuedSendDataBytes) {
    LOG(LS_ERROR) << "Can't buffer any more data for the data channel.";
    return false;
  }
  queued_send_data_.Push(new DataBuffer(buffer));
  return true;
}

guymguym · 2015-04-02T10:46:08Z

after fixing #184 locally and also fixing the previous issue by releasing the buffer from the scoped_ptr if breaking, i can now run the test with valgrind for longer time and now I get these issues which seem to be related to node-webrtc allocations:

==16199== Invalid free() / delete / delete[] / realloc()
==16199==    at 0x100AD094F: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==16199==    by 0x10A4101D9: void MessageWeakCallback<v8::Object, node_webrtc::DataChannel::MessageEvent>(_NanWeakCallbackData<v8::Object, node_webrtc::DataChannel::MessageEvent> const&) (datachannel.cc:131)
==16199==    by 0x10A411269: void _NanWeakPersistentDispatcher<v8::Object, node_webrtc::DataChannel::MessageEvent>(v8::Persistent<v8::Value>, void*) (nan.h:996)
==16199==    by 0x1001B738A: v8::internal::GlobalHandles::Node::PostGarbageCollectionProcessing(v8::internal::Isolate*, v8::internal::GlobalHandles*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001B6BCD: v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001C07C4: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GCTracer*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001BFDF6: v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollector, char const*, char const*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001A7A95: v8::internal::Factory::NewArgumentsObject(v8::internal::Handle<v8::internal::Object>, int) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x100325C13: v8::internal::Runtime_NewArgumentsFast(v8::internal::Arguments, v8::internal::Isolate*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1C76F6006361: ???
==16199==    by 0x1C76F60CA190: ???
==16199==    by 0x1C76F6209A3C: ???
==16199==  Address 0x10f2fac40 is 0 bytes inside a block of size 8,192 free'd
==16199==    at 0x100AD094F: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==16199==    by 0x1001B738A: v8::internal::GlobalHandles::Node::PostGarbageCollectionProcessing(v8::internal::Isolate*, v8::internal::GlobalHandles*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001B6BCD: v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001C07C4: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GCTracer*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001BFDF6: v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollector, char const*, char const*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001A7A95: v8::internal::Factory::NewArgumentsObject(v8::internal::Handle<v8::internal::Object>, int) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x100325C13: v8::internal::Runtime_NewArgumentsFast(v8::internal::Arguments, v8::internal::Isolate*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1C76F6006361: ???
==16199==    by 0x1C76F60CA190: ???
==16199==    by 0x1C76F6209A3C: ???
==16199==    by 0x1C76F600CCCD: ???
==16199==    by 0x1C76F6213686: ???
==16199== 
==16199== Invalid free() / delete / delete[] / realloc()
==16199==    at 0x100AD094F: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==16199==    by 0x1001B738A: v8::internal::GlobalHandles::Node::PostGarbageCollectionProcessing(v8::internal::Isolate*, v8::internal::GlobalHandles*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001B6BCD: v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001C07C4: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GCTracer*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001BFDF6: v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollector, char const*, char const*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001A7A95: v8::internal::Factory::NewArgumentsObject(v8::internal::Handle<v8::internal::Object>, int) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x100325C13: v8::internal::Runtime_NewArgumentsFast(v8::internal::Arguments, v8::internal::Isolate*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1C76F6006361: ???
==16199==    by 0x1C76F60CA190: ???
==16199==    by 0x1C76F6209A3C: ???
==16199==    by 0x1C76F600CCCD: ???
==16199==    by 0x1C76F6213686: ???
==16199==  Address 0x10f336ca0 is 0 bytes inside a block of size 8,192 free'd
==16199==    at 0x100AD094F: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==16199==    by 0x10A4101D9: void MessageWeakCallback<v8::Object, node_webrtc::DataChannel::MessageEvent>(_NanWeakCallbackData<v8::Object, node_webrtc::DataChannel::MessageEvent> const&) (datachannel.cc:131)
==16199==    by 0x10A411269: void _NanWeakPersistentDispatcher<v8::Object, node_webrtc::DataChannel::MessageEvent>(v8::Persistent<v8::Value>, void*) (nan.h:996)
==16199==    by 0x1001B738A: v8::internal::GlobalHandles::Node::PostGarbageCollectionProcessing(v8::internal::Isolate*, v8::internal::GlobalHandles*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001B6BCD: v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001C07C4: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GCTracer*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001BFDF6: v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollector, char const*, char const*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1001A7A95: v8::internal::Factory::NewArgumentsObject(v8::internal::Handle<v8::internal::Object>, int) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x100325C13: v8::internal::Runtime_NewArgumentsFast(v8::internal::Arguments, v8::internal::Isolate*) (in /Users/gu/.nvm/v0.10.33/bin/node)
==16199==    by 0x1C76F6006361: ???
==16199==    by 0x1C76F60CA190: ???
==16199==    by 0x1C76F6209A3C: ???
==16199==

guymguym · 2015-04-02T10:55:36Z

the first free is coming from datachannel.cc:131

NAN_WEAK_CALLBACK(MessageWeakCallback)
{
  P* parameter = data.GetParameter();
**  delete[] parameter->message;
  parameter->message = NULL;
  delete parameter;
  //NanAdjustExternalMemory(-parameter->size);
}

guymguym · 2015-04-02T11:09:42Z

I found that webrtc already fixed the code for SendQueuedDataMessages ~2 months ago to avoid deleting buffer and leaving in queue.

https://chromium.googlesource.com/external/webrtc/+/cceb166a3fd2724c679da7d093149b0511e8d99b%5E%21/#F0

@modeswitch can libwebrtc be updated? do you go to latest or pick specific patches?

void DataChannel::SendQueuedDataMessages() {
  ASSERT(was_ever_writable_ && state_ == kOpen);
  while (!queued_send_data_.Empty()) {
    DataBuffer* buffer = queued_send_data_.Front();
    if (!SendDataMessage(*buffer, false)) {
      // Leave the message in the queue if sending is aborted.
      break;
    }
    queued_send_data_.Pop();
    delete buffer;
  }
}

guymguym · 2015-04-02T22:33:58Z

OK, found the issue and updated the pull request with the fix.

apparently NanMakeWeakPersistent was called with the array as the handle, but should be the callback function according to the (docs)[https://github.com/rvagg/nan#api_nan_make_weak_persistent].

so @modeswitch to close this issue we need to pull fix(es) from webrtc to libwebrtc, and merge #182 .

fix #184, and bandwidth test to reproduce issue #171

guymguym · 2015-04-04T16:41:09Z

@modeswitch Thanks!

But this issue is still open without fixing the bug in webrtc -

https://chromium.googlesource.com/external/webrtc/+/cceb166a3fd2724c679da7d093149b0511e8d99b%5E%21/#F0

What is the plan about updating libwebrtc from upstream?

modeswitch · 2015-04-04T17:35:58Z

It looks like that patch will apply cleanly to libwebrtc. Easiest thing would be to cherrypick it from upstream.

guymguym · 2015-04-04T19:21:46Z

@modeswitch cherrypicking might be the fastest path to fix this issue.

for the long term I would prefer to see this project allowing to pick a specific revision from upstream webrtc as I suggested in #174 (which I see you closed).

guymguym · 2015-04-04T19:23:44Z

I added pull-request #186 that currently fails on this issue, and should hopefully pass once updating libwebrtc (though my tests are only on mac, so I hope linux builds will behave the same).

modeswitch · 2015-04-04T20:03:07Z

@guymguym The whole reason for using a fork of libjingle was to reduce the complexity for building the node bindings, which was a common complaint. Pre-built binaries didn't solve the problem for all platforms.

If you make a pull request with the upstream patch (make sure the commit hash is the same), I'll merge it.

Also, if you have a better way of maintaining the libjingle fork (via build scripts as you suggested) please make a pull request and we can discuss it.

guymguym · 2015-04-05T00:06:23Z

If you make a pull request with the upstream patch (make sure the commit hash is the same), I'll merge it.

@modeswitch I'm not sure how to do that technically. I forked libwebrtc, added upstream webrtc as remote (from https://chromium.googlesource.com/external/webrtc/), checkedout upstream/master to find the commit to cherry-pick which is this one:

commit cceb166a3fd2724c679da7d093149b0511e8d99b
Author: jiayl@webrtc.org <jiayl@webrtc.org>
Date:   Thu Jan 22 00:55:10 2015 +0000

    Fix a use-after-free when sending queued messages is aborted for blocked channel.

    BUG=4187
    R=pthatcher@webrtc.org

    Review URL: https://webrtc-codereview.appspot.com/39519004

    git-svn-id: http://webrtc.googlecode.com/svn/trunk@8119 4adac7df-926f-26a2-2b94-8c16560cd09d

so then I checkedout back to master, cheery-pick cceb166a3fd2724c679da7d093149b0511e8d99b, and then I get a different commit hash:

commit e5f6bf1b03e99fa8b93e5251160a6aeb4f2db08b
Author: jiayl@webrtc.org <jiayl@webrtc.org>
Date:   Thu Jan 22 00:55:10 2015 +0000

    Fix a use-after-free when sending queued messages is aborted for blocked channel.

    BUG=4187
    R=pthatcher@webrtc.org

    Review URL: https://webrtc-codereview.appspot.com/39519004

    git-svn-id: http://webrtc.googlecode.com/svn/trunk@8119 4adac7df-926f-26a2-2b94-8c16560cd09d

Although the diff is perfectly fine...
Can you explain how can I make the commit hash the same?

guymguym · 2015-04-05T00:27:04Z

According to this explanation it's not really possible -
http://stackoverflow.com/questions/14676715/cherry-pick-a-commit-and-keep-original-sha-code

modeswitch · 2015-04-05T00:40:55Z

@guymguym Ah, yeah. The repos have diverged so that won't be possible. I guess the next best thing is to mark the upstream commit in the commit log. Then at least we can figure out where the patch came from.

guymguym · 2015-04-05T00:49:28Z

done - js-platform/libwebrtc#5

guymguym added a commit to guymguym/node-webrtc that referenced this issue Apr 1, 2015

bandwidth test to reproduce issue node-webrtc#171

8af39dd

modeswitch closed this as completed in ce1b147 Apr 4, 2015

modeswitch pushed a commit that referenced this issue Apr 4, 2015

Merge pull request #182 from guymguym/develop

412dc2e

fix #184, and bandwidth test to reproduce issue #171

guymguym mentioned this issue Apr 4, 2015

bwtest improved and added to npm test #186

Merged

malloc: *** error for object 0x100000000: pointer being freed was not allocated #171

malloc: *** error for object 0x100000000: pointer being freed was not allocated #171

Comments

guymguym commented Mar 23, 2015

guymguym commented Mar 27, 2015

modeswitch commented Mar 27, 2015

guymguym commented Mar 27, 2015

modeswitch commented Mar 28, 2015

guymguym commented Mar 28, 2015

modeswitch commented Mar 28, 2015

guymguym commented Mar 28, 2015

modeswitch commented Mar 28, 2015

guymguym commented Mar 30, 2015

guymguym commented Apr 1, 2015

rosskukulinski commented Apr 1, 2015

guymguym commented Apr 1, 2015

guymguym commented Apr 1, 2015

rosskukulinski commented Apr 1, 2015

guymguym commented Apr 2, 2015

rosskukulinski commented Apr 2, 2015

guymguym commented Apr 2, 2015

guymguym commented Apr 2, 2015

rosskukulinski commented Apr 2, 2015

rosskukulinski commented Apr 2, 2015

guymguym commented Apr 2, 2015

rosskukulinski commented Apr 2, 2015

guymguym commented Apr 2, 2015

guymguym commented Apr 2, 2015

guymguym commented Apr 2, 2015

guymguym commented Apr 2, 2015

guymguym commented Apr 2, 2015

guymguym commented Apr 2, 2015

guymguym commented Apr 4, 2015

modeswitch commented Apr 4, 2015

guymguym commented Apr 4, 2015

guymguym commented Apr 4, 2015

modeswitch commented Apr 4, 2015

guymguym commented Apr 5, 2015

guymguym commented Apr 5, 2015

modeswitch commented Apr 5, 2015

guymguym commented Apr 5, 2015