Ошибка программы ядра project 64

Copy link

Contributor

Author

Opening Configure Controller immediately crashes/closes latest Project64 2.2.0.841 here. No error, just disappears.

Doesn’t crash after opening a rom. Only crashes before any rom has been started.

I know this sounds stupid, but have you guys tried a fresh download of Project64? And what version are you guys using, the latest stable or the latest from source?

Copy link

Contributor

Author

I tested latest from Github and latest from the alpha section of the forum. Zilmar’s buildbot.
http://forum.pj64-emu.com/forumdisplay.php?f=10

Just open/close a rom first before touching the controller settings. No crashing then. That’s the only way around it at the moment.

@tony971 It might seem like a stupid question, but I have to ask it. Also, this is Project64. It is a little more complicated than «is your modem turned on». 😆

Anyway, does this happen with 32 and 64-bit versions?

Huh, that’s weird. It isn’t even going to a useful spot in the source. What was the last version that worked? I haven’t had the issue, but then I haven’t built a new version in a week or so…

There have been 100+ commits in the past 10 days or so, massive code cleanup is in progress. I’m guessing to prepare for a new public release. I’ve been holding back on trying to do anything while this is happening. As current source is very much a work in progress. Too many cooks spoil the broth and all that…

Oh, maybe that is causing some issues. Hopefully they are temporary, especially if we are going to be releasing a new public stable release. I’m excited though. 😄

History shows it can be revealing issues that have always existed. A couple memory issues with plugins and 64-bit have always been in the code, but the EXE just lucked out and didn’t crash in terms of pure chance. Now that things are being restructured for a command-line version of the PJ64 core, the memory allocation is drastically different which reveals many hidden mistakes in the code that have always been there, like crashes.

RSP is under a full rewrite, only RSP interpreter configuration works.

This is not new to latest build

Thank you, @Squall-Leonhart . I wasn’t aware of that.

Should I wait for a fix for this soon or is there a recent build which I could be using before this is addressed?

The latest one I have here in my emulators folder is Project64-Dev-4.0.0-6090-96792b1. I’m not sure if it’s too old, but this version doesn’t show the issue.

Thank you again.

@dezraj : I am getting the same message on my system too, with the latest builds (on a laptop which has a discreet AMD GPU that supports both DirectX12 and OpenGL 4.3, and so meets the requirements of all Project64’s video-plugins). The most-recent build that works for me is the one named «Project64-Dev-4.0.0-6151», dated 6 July 2023. You can click here to download it.

@Squall-Leonhart : if certain-builds of the app are generally-expected by the team to not-work, would it not be possible to add a notice to the top of the https://www.pj64-emu.com/nightly-builds page, to save any confusion? For example:

⚠Builds newer than the 6 July 2023 («Dev-4.0.0-6151-353ef5e») release are known not to work at this time, due to major changes being underway. Please DO NOT contact us to report any errors, as we know you will encounter them!
✅ Please use either the 3.0.1 stable-release, or the 4.0.0-6151 testing-build, thank you

And then just remove or amend that message in the future, once newer-builds are again expected to work more-broadly?

The definition of a nightly build: «Everything in the repository as of a certain time of day gets built automatically» that includes breaking changes. Any and all nightly builds are expected to break stuff. They get reported, then they get fixed eventually and the report closed. This is basic «using beta/development software» stuff.

the changes I made to the RSP are needed to make it more accurate, the problem is it causes issues in the recompiler that cause it to crash.

I am working on a fix in that all the new code will need a setting turned on to use it. So once committed the RSP should act like it has before and I can keep working on the RSP getting it more accurate and then on the recompiler accurate and only when it is all working nicely turn the option from off by default to on.

But it does mean any of my changes should not break things going forward (unless you turn it on to use it)

usually it functions fine, and I plan to get it back to a state where it does. The change to the vector order had a bigger cascading effect than I thought.

Its cool, just do what you need to do to make pj64 better.

@flagrama : yes, of course alpha or nightly builds are expected to have random-bugs. But in this case, it is known that the most-recent builds will all definitely not work, which is quite a different-thing! So it’s not then unreasonable to expect either (1) warn users not to use those versions, or perhaps (2) just don’t offer downloads for them. I mean, is there any-value to the developers here in users reporting «I’m getting this error» for the team to reply «yeah, we know, that’s gonna happen». 🤷🏻‍♂️

Remember too that the general-advice around Project64 thesedays is «go with the latest stable-release (3.0.1), but if it doesn’t work on your PC and you’ve tried the various video-plugins, then download the latest nightly-build and test on that before reporting an issue on GitHub». Which at present would be bad-advice, as it’s known the latest nightlies will intentionally not work — and yet nothing on the downloads page warns users of that.

@Squall-Leonhart : yes, «nightly» does imply «construction zone», but there is a difference between builds which «may have the odd bug, so not recommended for general-use» and «intentionally will not work«. For the latter, there should be some warning to users to skip those builds, and state the most-recent build before major changes. The general-advice thesedays is for users to start with the most-recent stable (3.0.1), but if it doesn’t work on their PC, or particular games don’t work, to then try the latest dev-release… which is great, until, you-know… times when the latest Dev releases are known not to work, but an end-user isn’t aware of that! 🙃

Also, I’m not-sure what you’d mean by the workaround «only RSP interpreter configuration works»? I did try enabling «Always use interpreter core», but it didn’t work. So doing a Google suggests users would need to obtain an alternative RSP Plugin, so that Options > RSP Settings then becomes available in the app. But if that is indeed the case, why doesn’t this alternative RSP plugin simply ship with the app?

@dftf-stu I try to keep the nightly in a working condition while working on it. I have a fix I am working on and hopefully be able to commit to tomorrow. When it comes to the download page notification, I am the one who works on it. I have limited time so it is working on the site or the emulator. My guess it is better to get a fix in soon then latter than just put a notification on the site.

@project64 : (I was in the process of replying before your reply came in…)

Thanks for your work with the app! You’re just doing your coding and if stuff breaks, then it breaks. Nothing here is your fault. Someone-else involved in the team should be relaying with you, and if you advise «this is a major-change, so I expect it will break the app» they should then either (1) update the downloads page to advise end-users not to use those builds, or (2) decide if such builds should even be available for public-download to begin with.

That’s not down to you though… you just keep doing your thing. 👍🏻

technically I am the main person in the team, there is some loose alliances where people do help out, but it really comes down to just me, so if something is wrong it is my fault and my responsibility to fix it.

I changed the order of the vector register and had thought it was only really impacting the interpeter as the recompiler did not really change with it, and have had my focus on just testing the interpeter. But looking at it more recently and digging in to why the recompiler crashed, I understood the issue and now have to silo off that change so the recompiler can still work as it has till I get basically everything fixed 100%

Also, I’m not-sure what you’d mean by the workaround «only RSP interpreter configuration works»? I did try enabling «Always use interpreter core», but it didn’t work. So doing a Google suggests users would need to obtain an alternative RSP Plugin, so that Options > RSP Settings then becomes available in the app. But if that is indeed the case, why doesn’t this alternative RSP plugin simply ship with the app?

When using the inbox RSP, an additional option is added to the Debugger menu for the RSP configuration, under this is the CPU Method which defaults to Recompiler.

the current state of the RSP will boot if this is set to Interpreter, until Zilmar has pushed his fix into master.

im also having this problem

@kamikazilucas: the latest «Development» releases are known not to work at this time, due to major-changes being made.

The latest «dev-build» that should work fine is the one released on 6 July 2023 (titled Dev-4.0.0-6151-353ef5e). You can click here to download a ZIP file containing that version.

You could also use the older, but considered «stable», 3.0.1 release by downloading it via this link.

If you like, download both: as long as you copy the files inside each ZIP into a separate-folder, you can switch-between them on the same PC. All the settings for each-app are self-contained, so any-change you make in one won’t affect the other.

@project64: I don’t want to mis-advise the user above, so thought I’d check first… given the front-page for this project here on GitHub says it is written in «85.5% C++», then I would assume users must have the Microsoft Visual C++ 2015-2022 libraries installed on their PC for Project64 to run?

Just thought I’d check, as the README on here doesn’t mention they are required?

no requirements are needed, it is compiled in a way so you do not need that

@flagrama : yes, of course alpha or nightly builds are expected to have random-bugs. But in this case, it is known that the most-recent builds will all definitely not work, which is quite a different-thing!

@dftf-stu You seem to be confused on how these bug reports work and seem to think everything needs to be done immediately. You are impatient and give no time for fixes to be done. This bug report was posted 4 days ago. Squall messed with settings to see what stopped the issue for him and reported it for the user, and since it was in a part of the emulator that has been having work on it for the past few builds, warned that earlier builds will also cause issues.

While that’s happening, zilmar is also aware when bug reports get posted, and if the default settings are broken he’s going to start working on a fix or temporary workaround hack in the code. This takes time because you have to figure out the exact problem before you can start thinking about how you want to approach the fix or workaround.

While this is happening you’re here saying «you knew it was broken so you should mark it as such» and are asking people to waste time adding some kind of message or website functionality that will take more time and work than zilmar providing a fixed build will. Nobody knew it was broken until the bug report was made. The repository regulars don’t personally use every nightly build, and usually have custom settings so even if we had used them all there’s no telling any of of us would have even run into it. I only use pj64 when I need to do debugging, so I use interpreter everything and would not have run into it for example. zilmar especially won’t know because he’s focused on making the fixes, you can’t test literally everything works after changes (because there is no test suite for pj64 that would warn you for that, while unfortunate, at this point would take significant work and rewriting of the existing code to make it testable, but I do believe is on zilmar’s radar) so something is bound to break and not be found until an end-user finds it.

Zilmar is better at handling this impatience than either me or Squall, but you should really give him time to make the fixes rather than complaining for warning messages to be plastered everywhere, particularly since it is the development build where this stuff is expected.

Nobody knew it was broken until the bug report was made. The repository regulars don’t personally use every nightly build, and usually have custom settings so even if we had used them all there’s no telling any of of us would have even run into it. I only use pj64 when I need to do debugging, so I use interpreter everything and would not have run into it for example. zilmar especially won’t know because he’s focused on making the fixes, you can’t test literally everything works after changes (because there is no test suite for pj64 that would warn you for that, while unfortunate, at this point would take significant work and rewriting of the existing code to make it testable, but I do believe is on zilmar’s radar) so something is bound to break and not be found until an end-user finds it.

It was known

@flagrama: I’ll try and address some of your points.

No, I don’t think «everything needs to be done immediately». But the last-working Dev build is 6 July 2023, with 13 July 2023 and onwards showing the error the OP reported. I would think within the (nearly) six-weeks time a message could be added to a website? And while you say later «Nobody knew it was broken until the bug report was made», that surprises me. Surely on your Discord you’d ask for volunteers to download and test each-version, and report back? In my case, I downloaded 4.0.0.6152 soon after release, noticed the same error as the OP, but from my past-experience on here just thought «nah, no-point spending my time to report it, as they’ll only close my ticket within minutes advising they’re already aware of it», so I didn’t. I just keep a local note myself on which builds work (e.g. 4.0.0-6138 to 4.0.0-6151, and 4.0.0-6108 to 4.0.0-6120) and which ones don’t (e.g. 4.0.0.6131 to 4.0.0-6137, and 4.0.0-6152 to 4.0.0-6181) and assume broken ones are just supposed to be that-way. 🤷🏻‍♂️

And I would disagree I’m «impatient» with these things. I’ve logged tickets in the past for games I’ve had issues with, and you’ll note I’ve not added any updates or chases on any of them in ages (mostly because I’ve since stopped playing those games, and given how-many new Dev builds have been released since the time of the report, I’d question the value in keeping such tickets open anyway. I mean, you can find tickets on here going back to 2016 — should some of them not get closed-off by now, given they’ll be for since-discontinued releases of PJ64?) And if you look at other long-standing issues, such as if XP and Vista are actually still supported or not, or why «Always compress saved states» still exists, when it was said ages ago turning it off is not supported now and should be removed… then… why not just remove it? How long can it take to edit the «Configuration» form?

Squall providing feedback is helpful, sure… but only if explained in a way most-users can understand. Saying «only RSP interpreter configuration works» is fine, but what do you have to do within the app to apply that setting? Like most of your users of the app, I’m not a coder or developer, so I’d expect at-least the name of the setting to alter, or ideally where to find it in the app.

@flagrama: as a perfect-example of old tickets on here, how-about «Vigilante 8 bad performance ingame» (1283), which I won’t tag to avoid adding an update! It was raised on 9 March 2017, with the last-update being on the 27th of that same-month.

Is it worth leaving a ticket open for over 6 years, given that (assuming the OP was using the most-recent version of PJ64 at that time), they would have been using v2.3.2, which I doubt is still-supported now, given 3.0.1 is the current-stable?

Is there not any-policy on here about when tickets get closed due to age, or lack of any further replies? 🤔

Surely on your Discord you’d ask for volunteers to download and test each-version, and report back?

The Project 64 discord is mostly community-run. AFAIK zilmar will add people to the moderators if requested by the others or if he knows them from elsewhere, and occasionally replies to someone on there, but that’s about it. Most actual discussion happens on a Discord server with developers for other n64 emulators, rom hacks, and tools.

but from my past-experience on here just thought «nah, no-point spending my time to report it, as they’ll only close my ticket within minutes advising they’re already aware of it», so I didn’t.

If there is already a bug report then yes, it is unnecessary to add another. You should still report if you see new breaking behaviours though. Squall responses sound a lot like «we already know that» but might just be something he found by changing settings or looking in the code. It’s hard to tell which sometimes. It doesn’t necessarily mean it was known about previously.

I mean, you can find tickets on here going back to 2016 — should some of them not get closed-off by now, given they’ll be for since-discontinued releases of PJ64?

If the issue still occurs, the report should stay open. If you find a bunch that are invalid now perhaps you could make an issue listing them and someone can go through and close them. A lot of issues are due to inaccuracies in the emulator so are expected to be getting fixed over time in the 4.0 release cycle, but also might break again in between, so choosing when to close some of them is awkward.

if XP and Vista are actually still supported or not

If you can confirm it’s broken on stable I’d say that @DerekTurtleRoe or someone can throw up a PR that removes Windows XP from the list of supported OSes. Trying to get the emulator to work for it again while doing multiplatform in 5.0 should probably be attempted. Zilmar will probably try to get it fixed near the end of 4.0 development though with it known about. That’ll be a while though.

why «Always compress saved states» still exists, when it was said ages ago turning it off is not supported now and should be removed… then… why not just remove it? How long can it take to edit the «Configuration» form?

It’s not a broken default setting. It should get fixed in the future so ripping it out is not preferred by zilmar IIRC. That’s the kind of bug that gets looked at closer to release by zilmar. Someone else could try to fix it if they wanted before that though.

Squall providing feedback is helpful, sure… but only if explained in a way most-users can understand.

That’s just not going to happen most of the time tbh. You get used to it. You either have to ask him to clarify or find the option and add where it is in a comment.

«Vigilante 8 bad performance ingame» (1283), which I won’t tag to avoid adding an update! It was raised on 9 March 2017, with the last-update being on the 27th of that same-month.

Is it worth leaving a ticket open for over 6 years, given that (assuming the OP was using the most-recent version of PJ64 at that time), they would have been using v2.3.2, which I doubt is still-supported now, given 3.0.1 is the current-stable?

Is it fixed?

bah, and if you want to discuss this more, we should really move it to the Discussions tab and ping me. Really shouldn’t be doing this on an issue.

If you can confirm it’s broken on stable I’d say that @DerekTurtleRoe or someone can throw up a PR that removes Windows XP from the list of supported OSes. Trying to get the emulator to work for it again while doing multiplatform in 5.0 should probably be attempted. Zilmar will probably try to get it fixed near the end of 4.0 development though with it known about. That’ll be a while though.

My area has had really bad storms with blackouts and loss of internet as of late, so I haven’t been as active as I’d like. I’ve also been trying to improve my testing methodology and workflow a bit and it took longer than I thought. But I do have some changes staged in Git, just not commited yet. I have a large amount of things on my Project64 TODO list, this is one of them.

One thing I will say is that the requirements are definitely going to change once things like the new UI are done, I think that library only supports Windows 7 at the minimum, if I remember correctly.

@flagrama :

• Perhaps it might be an idea to start asking users if they could report-back when a build works and doesn’t? Or add a simple «Send feedback…» dialog into the app itself, and ask users if the build works or not, which would then submit some system-specs to you directly (e.g. OS, CPU, RAM, video-cards and their drivers, PJ64 version)?
• Without any sort-of «known issues» list, how can I judge as a user if something is worth reporting? Like Squall said, if it’s a development build, the clue is in the title — expect stuff to break. So… it’s hard to judge. I read at the changes-notes on the downloads page, saw lots of mentions of «RSP» and so thought «well, given there is lots of stuff happening around this RSP thing, I guess if I get an error-message relating to RSP it’s likely to be expected and so not-worth reporting». 🤔
• There are lots of existing bug-reports on here, hence my suggestion to close some off. Do I know if that issue (1283) is still ongoing? No… it might well be. But also it’s equally-likely the user may no-longer be actively playing N64 games, may have moved to a different emulator (e.g. simple64), or is using a later version of the app on a newer PC or laptop. I would suggest for tickets that are six-years old, it is unlikely to be worthwhile leaving them open.
• The last I was advised on XP it was that support wanted to be retained, but currently any of the recent dev or stable-releases are broken, due to Discord being enabled by-default. Users have to know to edit the Project64.cfg file to disable it. On Vista, the app expects an API change that only occurred in Windows 7. There is an open-ticket on here with this info. I could re-test the latest versions if you like — but is there any value in me doing so unless the plan actually is for them to be supported?
• Instead of ripping the setting out, maybe just ship with it as disabled (greyed-out) on the form so it cannot be turned-off by a user until the issue is addressed?

@DerekTurtleRoe : hmm, I wonder which library you’re referring to? 🤔

I’ve seen some projects recently migrating from Qt5 to Qt6, which has then broken Windows 7 and 8.x support, as Qt6 requires 64-bit Windows 10 or later. For example, the Transmission team were caught-out by this, and have since released a Qt5 build (similar to what qBittorrent also offer). And DuckStation have only in the last week or-so migrated from Qt5 to Qt6, so any Windows 7 or 8 users are in for a shock soon once they get the latest update, then find the app no-longer opens! 😲

Looks like https://wtl.sourceforge.io/ might be Vista+ which is the only UI-related library I can think of that Derek is talking about. zilmar hates Qt and would probably never use it.

I can confirm that as of build 4.0.0-6195-625f532 the games are back to running again as far as I’ve tested.

Thank you zilmar and Squall for your work. Thank you all the others too, especially @dftf-stu for caring about the user experience. You are a good observer and I think you should contribute more with your observations.

• BB code is On
• Smilies are On
• [IMG] code is On
• [VIDEO] code is On
• HTML code is Off