Closed neonphog closed 1 year ago
@neonphog what can I provide?
@Connoropolous - Sorry, I meant add more info to the panic error itself, not this issue : )
As far as identifying problems like this and more quickly fixing them goes: I don't suppose you would know how to set up a github actions macos runner to build for ios / execute in an ios vm or something?
ah ok yep. I'll take a check for approaches to ios
@neonphog what do you think your schedule is for getting into this?
Do you think the error message would be reported if there was an error message in the Go side code of the panic?
@Connoropolous - I've got a lot on my plate, and am out next week. Could it wait until after? If not I can try to squeeze it in.
My first step would be to see if there was some way to get a stack trace or something out of the go panic to pass along. I'm not super familiar with the error handling in go. We're also stripping out debug symbols, so we might need to stop doing that temporarily.
I understand. If it waits it’ll shoot down any chance of hitting the DWeb Camp objective, so that’d really be unfortunate. I have just been trying to assist Art and Eric in having a solid way to have mobile holochain use at DWeb. I am not going myself.
If you could squeeze anything in we’d really appreciate it, but don’t go too far out of your way, and let us know if you just think it’s a dead end for now.
Update: there's been a move to a different approach for DWeb Camp, so the pressure is off for this.
I realized again that iOS doesn’t support dylibs so this is more of a fundamental incompatibility. Unless the go code could be exported and loaded as a static lib instead. @neonphog why was the shared/dynamic lib approach chosen, out of curiosity?
@Connoropolous - golang didn't support compiling to a static lib on windows until the recently released 1.20. And even with that, it'll only compile with mingw which is incompatible with rust which compiles with msvc.
We can support static linking on non-windows platforms, it just hasn't been a priority since we needed to get the dynamic linking working for windows first.
This is another pull for getting the static linking going for non-windows platforms.
Oh ok, I see. well that opens up a potential second avenue, in addition to the Rust webrtc backend, for ios support
@Connoropolous
golang stack traces are now included with golang panic reports -- for when we get back to working with this.
nice! thank you.
This item has been open for 30 days with no activity.
@abe-njama I think this is blocking me now. I should add that this would be also needed for android.
@guillemcordoba - why would this be needed for android? I'm able to run it fine with the dynamic linking.
@neonphog I'm running into this error:
10-18 17:29:03.371 14276 14276 W ContentCatcher: Failed to notify a WebView
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: FATAL PANIC PanicInfo {
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: payload: Any { .. },
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: message: Some(
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: filed to write go lib: Custom { kind: PermissionDenied, error: PathError { path: "/data/local/tmp/.tmpGVzcqi", err: Os { code: 13, kind: PermissionDenied, message: "Permission denied" } } },
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: ),
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: location: Location {
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: file: "/home/guillem/projects/holochain/core/tx5/crates/tx5-go-pion-sys/src/lib.rs",
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: line: 127,
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: col: 25,
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: },
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: can_unwind: true,
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: }
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: thread 'tokio-runtime-worker' panicked at /home/guillem/projects/holochain/core/tx5/crates/tx5-go-pion-sys/src/lib.rs:127:25:
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: filed to write go lib: Custom { kind: PermissionDenied, error: PathError { path: "/data/local/tmp/.tmpGVzcqi", err: Os { code: 13, kind: PermissionDenied, message: "Permission denied" } } }
10-18 17:29:03.373 14276 14314 I RustStdoutStderr: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
That's with Android 10, target android SDK 33, with the latest code from this repository, in my Redmi Note 7 phone. In my first attempt, it ran fine, but then subsequent runs run into this issue.
I'm not seeing this issue in the CI of my fork that runs SDK 33, but I am seeing other issues as well there: https://github.com/guillemcordoba/tx5/actions/runs/6561529206/job/17821414550
@guillemcordoba - Okay, so you need it to run on Android api level 33? The first step would be for me to get that working in CI.
The permission denied error you posted is about trying to write a tempfile... so we'll need to figure that out before we know if it's having trouble loading the dynamic library.
The other errors in the link you provided seem like it's having trouble with the network, but that would indicate it's able to execute functions in the dynamic lib just fine.
Yeah I am forced to run android api level 33. I assumed from the error message meant that tx5 wanted to write the dynamic library executable into the temporary directory before executing it, so then moving to having tx5 be statically linked would also solve this problem. It's interesting that it works on my CI...
Would you prefer I open another issue with this error?
@guillemcordoba
I'm hesitant to start up the static linking work again, both because it's going to be a significant effort, but also because it'll mean we have to maintain two divergent code paths (since window requires the dynamic linking).
If iOs is a near-term priority, perhaps, as you suggest, it would be best to proceed with this work rather than diagnosing the dynamic linking problems on Android.
Can you give some priority context? Thanks!
Well I only know what I need/would like, which is to be able to publish a holochain app to the play store and to the apple store in the next few months to start to do experiments in the real world in a local village and start to gather feedback from that. I know that holochain-mobile is a priority for the core team, so that's why I thought that solving this issue would have to be done anyway in the near future. Or maybe moving to webrtc-rs would also be an option, if that's stable enough, not sure.
I think @abe-njama would be the person to address how much of a priority this is.
Either way, I'll try to investigate what's the problem with the error I'm seeing, also ironing out the networking issues with android SDK 33 seems necessary...
All good. I'll go ahead and get started on the static linking work :+1:
@guillemcordoba - I can continue with this for ios, but it looks like it's a no-go (hehe, accidental pun) for android:
@neonphog Ohh mmm that's unfortunate... Thanks anyway. I'll get back to you when I know more on my side.
Turns out this wasn't as big a lift as I was worried it might be. Static linking is now enabled for all targets except windows and android. I'll start next on the android api level 33 CI runner.
oh my! this is exciting. I may have to take a peek in this direction again and try to get my iOS build working.
@neonphog will you be issuing a release and updating holochain to it this week?
Thanks so much @neonphog !
@neonphog will you be issuing a release and updating holochain to it this week?
Sure, I can get the ball rolling on that today
First step would be to see if we can add more information to this to figure out what the actual problem is : )
Original report: https://hackmd.io/_CFnGaWvQg6Ys3DxZblmug#May-27