IPFS crashes, and then crashes the browser

[lightninglu10]

• Version: 0.25.0
• Platform: JS
• Subsystem:

Type: Bug

Severity: High

Description: After a certain amount of time running, IPFS crashes at some point in the browser which then our app to crash. Not sure exactly what's going on, but we see memory continuously being allocated.

Also, if you have internet, and then turn your internet off, our app crashes as well. So whenever IPFS disconnects, there seems to be some error state that kills the whole app. How should we handle this?

Steps to reproduce the error:

Will setup JSBIN later

[victorb]

Trying to reproduce this with the example that is inside the examples/exchange-files-in-browser directory, by doing the following: (I'm on commit 07228a022bff4d9630132c649d92017c3e7f1a68)

• Start the example node
• Start a node with the CLI
• Add a file with the CLI node
• Connect the example node with the CLI node
• Try to get the file from the browser

And everything is working as expect. Could be something else with your application that creates the crashes? Would be interesting to know why you think js-ipfs is behind the crashes.

Also, tried turning off my connectivity as well during testing, but saw no difference.

[victorb]

Now when #941 has been fixed, I'm wondering if you're still experiencing these crashes?

If not, it would be helpful to have a small case that reproduces this issue.

[ghost]

Even if #941 fixed it, it'd be good to have test case for this -- a simple 403 shouldn't crash the browser

[lightninglu10]

This is still an issue. I'm going to post something soon that shows the issue.

[magik6k]

I had this happen with my app when sending a series of dag-cbor objects between browsers.

• open https://ipfs.io/ipfs/QmVXyT5LexveeRws3quvEwzRz3YE9kuXwEy2wCKK4UC8ob/ in firefox and in chromium incognito (chromium has broken caching, this is likely thing for a different issue), this uses js-ipfs v0.25.1 from npm.
• When drawing things is one window, they should appear in the other
• When drawing short lines fast one of the browser tabs will crash (usually chromium one)
• Relevant source: https://github.com/magik6k/milky-whiteboard/blob/master/src/main/scala/eu/devtty/mboard/canvas/Chain.scala

[lightninglu10]

So I'm trying to put an example online, but getting a different error now:

http://ipfstest.quantfive.org/

Uncaught TypeError: Cannot read property 'generateKey' of undefined
    at Object.exports.generateKey (ipfs.min.js:29)
    at Object.generateKeyPair (ipfs.min.js:155)
    at Object.exports.generateKeyPair (ipfs.min.js:155)
    at cb (ipfs.min.js:4)
    at nextTask (ipfs.min.js:2)
    at exports.default (ipfs.min.js:2)
    at Function.exports.create (ipfs.min.js:4)
    at waterfall (ipfs.min.js:226)
    at nextTask (ipfs.min.js:2)
    at next (ipfs.min.js:2)

Anyone know what's up with this?

@victorbjelkholm @lgierth

[haadcode]

This might be the same bug as #950 (Firefox - crashes with excessive thread activity), so cross posting here to make sure all the information is available.

As a side, the bug report re. generateKey() has also been observed in the orbit-web bug linked in the issue ^

[lightninglu10]

@haadcode thanks for alerting. This is exactly the same behavior I've been seeing. Gonna join in on that thread when I have more info.

[daviddias]

Hi @lightninglu10, see both:

• Firefox - crashes with excessive thread activity #950 (comment)
• Firefox - crashes with excessive thread activity #950 (comment)

The tl;dr; is that there are two main issues: a) WebRTC consumes too much resources and b) We don't close connections. I propose there some ways to mitigate the issue while we get a robust solution for everyone. Thanks for the patience and the bug report! :)

[lightninglu10]

Hey @diasdavid I looked more into it and I'm not using webRTC but getting similar behavior in the crashing to the other issue.

In that case not sure what the problem is!

And also, in re: closing connections, I'm only connected to my local IPFS backend node that I setup and disconnected from every other node. So would that be an issue here?

[daviddias]

@lightninglu10 are you sure you are not using WebRTC at all? Could you show your config file (just the part that has Addresses.Swarm)?

[lightninglu10]

I'm not using any config. I init IPFS with just IPFS(). I also disconnect (or try -- idk if it works) from all peers and only connect to my local IPFS go node.

…

On Aug 24, 2017, at 11:39 PM, David Dias ***@***.***> wrote: @lightninglu10 are you sure you are not using WebRTC at all? Could you show your config file (just the part that has Addresses.Swarm)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[daviddias]

@lightninglu10 if you are not touching the config it means you are indeed using WebRTC (which is the default).

Check how to config your IPFS node in this readme section -- https://github.com/ipfs/js-ipfs#advanced-options-when-creating-an-ipfs-node.

Also, visit the examples -- https://github.com/ipfs/js-ipfs/tree/master/examples -- they will help you understand the inner workings.

Please do keep questions coming with anything that is not clear, it helps us think how to improve docs! :)

[lightninglu10]

Oh really? I thought because of this: https://github.com/ipfs/js-ipfs#is-there-webrtc-support-for-js-ipfs-with-nodejs

that we would have to specify webRTC with modules and addresses. I'll look into the master examples to understand better.

[daviddias]

https://github.com/ipfs/js-ipfs#is-there-webrtc-support-for-js-ipfs-with-nodejs is just for Node.js, in the Browser it runs by default. You can disable WebRTC in the browser with:

const node = new IPFS({
  config: {
    Addresses: {
      Swarm: []
    }
  }
})

Just this :) It will overload the default config file https://github.com/ipfs/js-ipfs/blob/master/src/core/runtime/config-browser.json

[lightninglu10]

For now, disabling WebRTC in the browser seems to work. I think we lose some of the functionalities of JS-IPFS but going to close the issue for now.

[mitra42]

Did you figure out what JS-IPFS features get disabled ? When I try it, it clearly disables IIIF, I think its disabling pubsub, but also the IIIF retrieval.

[daviddias]

@mitra42 It doesn't disable PubSub, only disables that automatic connection between Browser Peers as there is no other transport that the browser can use to connect directly to another browser.

Another route is to use WebSockets and Relay creating 2 hop connections.

[mitra42]

We don't really care what transport we are using - that should be something for IPFS to figure out not the app - BUT the problem does seem to be that if there is no direct browser-browser connection, then IPFS is no longer being a decentralized file system. Can we have that call you suggested on another thread.

[daviddias]

BUT the problem does seem to be that if there is no direct browser-browser connection, then IPFS is no longer being a decentralized file system

That is an incorrect statement. P2P means there is connectivity from a Peer to another Peer, independently of how hops a connection needs to do to reach its destination. In IPFS and libp2p land, we not only respect the end to end principle, we also encrypted and authenticate every connection giving you stronger guarantees than a regular socket connection.

The Internet is P2P, every time you make a dial, the packets from your machine are routed through multiple set ups of multiple nodes. There are no direct connections, even in machines in the same Lan, a Router is used.

The WebRTC connection is P2P in the sense as it uses packet switching underneath as well.

IPFS currently supports WebRTC as a transport to create this direct (as in, the transport handles getting the packets to the other peer) and we will support Circuit Relay (where an IPFS node acts as a router for another node, this is great for serious NAT conditions for use cases like this one) and in the future we will have full Packet Relay (aka Packet Switching) at the application level.

You can be creative and have a node with PubSub acting as a Relay for your PubSub messages as we finish up the rest of the work.

re: call

Absolutely. To ensure our time discussing is productive, can you send me a list of questions you have by email and a proposed agenda? It is a good practice to have everything written down for async and distributed projects.

[mitra42]

I'm fully aware how IP & Routing works, and that isn't my point. Its that if we go through a fixed relay then its no longer decentralized. There is a single point of failure.

I don't have a problem doing that as an interim while other things are fixed, except that I have no way to understand what you mean by "Another route is to use WebSockets and Relay creating 2 hop connections."