When saving to NVRAM (either in the test menu or on the first boots), jubeat knit crashes. The issue occurs on datecode 2011011400 with knit APPEND running btools 5.44 with file from jb-03.zip, both on my personal machine and on my cabinet.
Logs
From my personal machine only.
log-crash.txt, log when crashing after first boot (with prop/defaults/[...].xml freshly copied to dev/nvram/)
log-second-boot.txt, log when crashing after second boot (where it tells you to turn off the switch and reboot. alt-f4'ing causes the crash)
# Description
When saving to NVRAM (either in the test menu or on the first boots), jubeat knit crashes. The issue occurs on datecode 2011011400 with knit APPEND running btools 5.44 with file from jb-03.zip, both on my personal machine and on my cabinet.
# Logs
From my personal machine only.
1. [log-crash.txt](https://github.com/djhackersdev/bemanitools/files/12139843/log-crash.txt), log when crashing after first boot (with prop/defaults/[...].xml freshly copied to dev/nvram/)
2. [log-second-boot.txt](https://github.com/djhackersdev/bemanitools/files/12139844/log-second-boot.txt), log when crashing after second boot (where it tells you to turn off the switch and reboot. alt-f4'ing causes the crash)
3. [log-crash-saving-shop-name.txt](https://github.com/djhackersdev/bemanitools/files/12139848/log-crash-saving-shop-name.txt), log when crashing after saving shop name.
# Possible causes
They all seem to have these errors in common, save for log-second-boot which only has the first line:
```
F:vfs: read: desc 80060002 != AVS_DTYPE_FS
M:netlog: > F:vfs: read: desc 80060002 != AVS_DTYPE_FS
M:xrpc: apply: cannot get url: "netlog"
W:netlog: xrpc_apply() failed.
```
I hope to investigate further, time allowing. Possibly an issue with incomplete prop files.
> Incomplete prop files? In my data? It's more likely than you think.
# Weird log stuff
Of note: logs to file (using -Y log.txt) generally stop after this block:
```
I:jbhook2: -------------------------------------------------------------
I:jbhook2: ---------------- Begin jbhook mwindow_create ----------------
M:xrpc: verbose 0, text_xml 0, plain 0.
I:jbhook2: -------------------------------------------------------------
M:xrpc: services.get
```
I had a debugger attached, so I was able to grab the rest of the logs from stdout and append them to the incomplete logfile. Separate bug?
Also mentioned in #92.
cc @mon
This is fixed in #257, with a pre-release build available at https://mon.im/jbhook1.dll
I'll delete that file once the PR is merged, but I've been dragging my feet a bit.
This is fixed in #257, with a pre-release build available at https://mon.im/jbhook1.dll
I'll delete that file once the PR is merged, but I've been dragging my feet a bit.
On July 23, 2023 11:54:33 PM EDT, Will @.***> wrote:
This is fixed in #257, with a pre-release build available at https://mon.im/jbhook1.dll
I'll delete that file once the PR is merged, but I've been dragging my feet a bit.
Thank you!
On July 23, 2023 11:54:33 PM EDT, Will ***@***.***> wrote:
>This is fixed in #257, with a pre-release build available at https://mon.im/jbhook1.dll
>I'll delete that file once the PR is merged, but I've been dragging my feet a bit.
>
>--
>Reply to this email directly or view it on GitHub:
>https://github.com/djhackersdev/bemanitools/issues/258#issuecomment-1647159026
>You are receiving this because you authored the thread.
>
>Message ID: ***@***.***>
knit can't find the emulated P3IO with that DLL - I'm guessing this may have to do with this being jbhook1 while knit requires jbhook2. Do those fixes need to be ported over to jbhook2?
knit can't find the emulated P3IO with that DLL - I'm guessing this may have to do with this being jbhook1 while knit requires jbhook2. Do those fixes need to be ported over to jbhook2?
Just had a look, and no. While knit still performs the same checks and creates a config, it immediately destroys the config afterwards because as a DLL game, it doesn't need to boot AVS (jb1 does, however).
Check your avs-config.xml - the nvram section should be defined:
Just had a look, and no. While knit still performs the same checks and creates a config, it immediately destroys the config afterwards because as a DLL game, it doesn't need to boot AVS (jb1 does, however).
Check your avs-config.xml - the nvram section should be defined:
```xml
<nvram>
<fstype __type="str">fs</fstype>
<device __type="str">dev/nvram</device>
<option __type="str"></option>
</nvram>
```
Having nvramfs options for the fs filetype is not really a good thing, I'd recommend removing that (though it shouldn't break anything really). Are you using the provided gamestart-03.bat? Does the game folder contain dev/nvram and dev/raw and does dev/nvram contain coin.xml and eacoin.xml?
Having nvramfs options for the fs filetype is not really a good thing, I'd recommend removing that (though it shouldn't break anything really). Are you using the provided gamestart-03.bat? Does the game folder contain dev/nvram and dev/raw and does dev/nvram contain `coin.xml` and `eacoin.xml`?
....oh goodness, this whole time I'd confused knit with ripples, then your later posts had me thinking "huh? guess we're doing knit now".....
I finally get it. Here's a bit of an idea then - can you try adding ifs layeredfs in verbose mode, so I can get a nice log of all file accesses? i think it will make the exact issue clear
....oh goodness, this whole time I'd confused knit with ripples, then your later posts had me thinking "huh? guess we're doing knit now".....
I finally get it. Here's a bit of an idea then - can you try adding ifs layeredfs in verbose mode, so I can get a nice log of all file accesses? i _think_ it will make the exact issue clear
ifs_hook.log after first boot is blank ifs_hook.log after second boot (the "test menu -> turn off the switch and reboot" situation) ifs_hook.log after saving shop name/area
[geez if you wanted to send me a trojan you should've just said so](https://www.virustotal.com/gui/file/3d1882ad93a40c8748aa77f63604b1c51c9e2138b2417d186205d5e6ee3d7c93)
(i kid)
ifs_hook.log after first boot is blank
[ifs_hook.log](https://github.com/djhackersdev/bemanitools/files/12207590/ifs_hook.log) after second boot (the "test menu -> turn off the switch and reboot" situation)
[ifs_hook.log](https://github.com/djhackersdev/bemanitools/files/12207594/ifs_hook.3rd.boot.log) after saving shop name/area
Oh wonderful, it's crashing aggressively enough to truncate the layeredfs logs ._. Can you add --layered-devmode as well? (this flushes all logs as they are written) Thanks for running all these tests for me, I can't replicate the issue locally at all so this is super helpful
Oh wonderful, it's crashing aggressively enough to truncate the layeredfs logs ._. Can you add `--layered-devmode` as well? (this flushes all logs as they are written) Thanks for running all these tests for me, I can't replicate the issue locally at all so this is super helpful
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
When saving to NVRAM (either in the test menu or on the first boots), jubeat knit crashes. The issue occurs on datecode 2011011400 with knit APPEND running btools 5.44 with file from jb-03.zip, both on my personal machine and on my cabinet.
Logs
From my personal machine only.
Possible causes
They all seem to have these errors in common, save for log-second-boot which only has the first line:
I hope to investigate further, time allowing. Possibly an issue with incomplete prop files.
Weird log stuff
Of note: logs to file (using -Y log.txt) generally stop after this block:
I had a debugger attached, so I was able to grab the rest of the logs from stdout and append them to the incomplete logfile. Separate bug?
Also mentioned in #92.
cc @mon
This is fixed in #257, with a pre-release build available at https://mon.im/jbhook1.dll
I'll delete that file once the PR is merged, but I've been dragging my feet a bit.
Thank you!
On July 23, 2023 11:54:33 PM EDT, Will @.***> wrote:
knit can't find the emulated P3IO with that DLL - I'm guessing this may have to do with this being jbhook1 while knit requires jbhook2. Do those fixes need to be ported over to jbhook2?
Just had a look, and no. While knit still performs the same checks and creates a config, it immediately destroys the config afterwards because as a DLL game, it doesn't need to boot AVS (jb1 does, however).
Check your avs-config.xml - the nvram section should be defined:
Yup:
Having nvramfs options for the fs filetype is not really a good thing, I'd recommend removing that (though it shouldn't break anything really). Are you using the provided gamestart-03.bat? Does the game folder contain dev/nvram and dev/raw and does dev/nvram contain
coin.xmlandeacoin.xml?Will do going forward o7
Yes, modified to account for modules being in a modules/ folder:
Contents of gamestart.bat
Sí
はい
Full filetree of my data folder
In which case, send logs. Can do it via email if you prefer not loading up the issue.
Are the logs in my first post okay?
....oh goodness, this whole time I'd confused knit with ripples, then your later posts had me thinking "huh? guess we're doing knit now".....
I finally get it. Here's a bit of an idea then - can you try adding ifs layeredfs in verbose mode, so I can get a nice log of all file accesses? i think it will make the exact issue clear
geez if you wanted to send me a trojan you should've just said so
(i kid)
ifs_hook.log after first boot is blank
ifs_hook.log after second boot (the "test menu -> turn off the switch and reboot" situation)
ifs_hook.log after saving shop name/area
Oh wonderful, it's crashing aggressively enough to truncate the layeredfs logs ._. Can you add
--layered-devmodeas well? (this flushes all logs as they are written) Thanks for running all these tests for me, I can't replicate the issue locally at all so this is super helpfulSure thing - I won't be back at that machine/cab for a hot sec but I'll make sure to let you know when I am!
ifs_hook 1st boot.log
ifs_hook 2nd boot.log
ifs_hook 3rd boot.log
Here you go.
Ooh, now this is interesting. I have a suspicion - copy
prop\ea3-config.xmltodev\nvram\ea3-config.xmlIt works! Workaround or permanent solution? (Either way, thanks!)
Permanent solution, we should have been copying that in in gamestart-03.bat
Good enough! Thanks!
I just realized why the issue didn't auto-close, and why you'd ostensibly want to keep it open until the PR is merged. Whoops.