Signed Bar crashed on execution #2
Comments
|
Interesting. That's not good. I haven't tried a signed bar yet (been working with developer builds). ----- Original Message ----- Hey Jeremy, Have you successfully exported a signed bar for dosbox and run in on you playbook? When I run in debug mode there are no issues but my signed bar file crashes in less then a second after the standard blackberry splash screen appears. I know I am not the only one that has had this issue either. Are there any logs that I can check or can you think of anything for me to check in the code? Thx, Reply to this email directly or view it on GitHub: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
|
Issue resolved...well the cause is identified and I have a work around for my system. For some reason LD_LIBRARY_PATH is not getting set as an entry point in the manifest.mf file. It is strange because it is set fine in my debug bar files. I believe this is related to some issues I had with my NDK installation. Initially I had set up NDK and the dosbox project and I had to enter the LD_LIBRARY_PATH in the environment variables in properties. I had originally only set it up for debug. Then I had some issues with the project and I could not figure out why it was not longer working properly so I removed everything(that I know of) and reinstalled the NDK and then imported the dosbox project from scratch and set the workspace to a completely different location. This time however I did not need to set the LD_LIBRARY_PATH variable, it just worked, but as we see it is only working for the debug bar. So I wonder if something is left over from the original installation that is overriding my environment variable setting in the current project. Either way my work around is to export without signing, add the LD_LIBRARY_PATH entry to the manifest.ml file and sign from the command line. EDIT: The other poerson I know who was having this issue said it was because his manifest.ml file had debug mode = True. When he set it to false he was successful as well. |
|
Thanks for the update. That seems pretty strange. I'll try to reproduce from my end and see if there's a bug to file against the NDK. -----Original Message----- Issue resolved...well the cause is identified and I have a work around for my system. For some reason LD_LIBRARY_PATH is not getting set as an entry point in the manifest.mf file. It is strange because it is set fine in my debug bar files. I believe this is related to some issues I had with my NDK installation. Initially I had set up NDK and the dosbox project and I had to enter the LD_LIBRARY_PATH in the environment variables in properties. I had originally only set it up for debug. Then I had some issues with the project and I could not figure out why it was not longer working properly so I removed everything(that I know of) and reinstalled the NDK and then imported the dosbox project from scratch and set the workspace to a completely different location. This time however I did not need to set the LD_LIBRARY_PATH variable, it just worked, but as we see it is only working for the debug bar. So I wonder if something is left over from the original installation that is overriding my environment variable setting in the current project. Either way my work around is to export without signing, add the LD_LIBRARY_PATH entry to the manifest.ml file and sign from the command line. Reply to this email directly or view it on GitHub: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
|
Here's the answer from the NDK team: The first beta releases of the NDK did not automatically add the LD_LIBRARY_PATH variable into the bar-descriptor.xml file as the 1.0 release does. The application launch configuration would add it on-the-fly when building development BARs, which is why those worked, but the Export Release Wizard did not. Adding this into the bar-descriptor.xml ensure that the Export Release was consistent with other BAR packaging methods. However, you may still have a bar-descriptor.xml that doesn't have the LD_LIBRARY_PATH environment variable. In that case, you should see a warning on the file that has a quick-fix (Cmd+1 on Mac, Ctrl+1 on other platforms) that adds it. In my case, the descriptor XML files do not have this quick fix applied, so that's why you saw the problem. Sorry for the problem, I'll fix it up shortly. -----Original Message----- Issue resolved...well the cause is identified and I have a work around for my system. For some reason LD_LIBRARY_PATH is not getting set as an entry point in the manifest.mf file. It is strange because it is set fine in my debug bar files. I believe this is related to some issues I had with my NDK installation. Initially I had set up NDK and the dosbox project and I had to enter the LD_LIBRARY_PATH in the environment variables in properties. I had originally only set it up for debug. Then I had some issues with the project and I could not figure out why it was not longer working properly so I removed everything(that I know of) and reinstalled the NDK and then imported the dosbox project from scratch and set the workspace to a completely different location. This time however I did not need to set the LD_LIBRARY_PATH variable, it just worked, but as we see it is only working for the debug bar. So I wonder if something is left over from the original installation that is overriding my environment variable setting in the current project. Either way my work around is to export without signing, add the LD_LIBRARY_PATH entry to the manifest.ml file and sign from the command line. Reply to this email directly or view it on GitHub: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
|
That solution worked, I can now sign using momentics without issue. Thanks Again. So what are your plans with dosbox? What amount of contribution are you looking for from the outside world? |
|
That's a tough question. My idea originally was to put dosbox up as more of a sample project to demonstrate an application on PlayBook, not with the intention of forking dosbox but rather stabilizing the port enough that it could be contributed upstream. I figured it might also be useful for people who wanted to package up older games to package up as apps. In terms of improvements, there's at least the serious problem that the current port doesn't use the fastest ARM core available (it uses the core built for size, not speed). I had been getting crashes with the other one when I first tried it. The other performance issue I noticed was mainly in graphics that fade in/out. There were some suggestions that changing the underlying SDL surface would improve performance here, but that's a problem with the current SDL port - it doesn't support the other surface types that might improve it. There are also various improvements that could be made to TouchControlOverlay specifically for Dosbox, and it's a bit of a gray area where those changes should be made. For example, control configurations that are selectable for different games. What were your hopes for dosbox? I was happy to see that you were interested enough to get it working. -----Original Message----- That solution worked, I can now sign using momentics without issue. Thanks Again. So what are your plans with dosbox? What amount of contribution are you looking for from the outside world? Reply to this email directly or view it on GitHub: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
|
Ultimately I would love to see a stable usable version properly distributed on app world as, I think there is a lot of interest in this. One of my first thought was about enhancing the interface to allow multiple configuration, I have also seen the performance issues that you mention. I think both of these would have to be cleared up. That said besides the performance it looks like it works quite well with a bluetooth keyboard. Is this not the latest version of sdl? or is it just the port that is not supporting multiple surfaces? |
|
It is the port that doesn't support overlays and 'hardware' surfaces. ----- Original Message ----- Ultimately I would love to see a stable usable version properly distributed on app world as, I think there is a lot of interest in this. One of my first thought was about enhancing the interface to allow multiple configuration, I have also seen the performance issues that you mention. I think both of these would have to be cleared up. That said besides the performance it looks like it works quite well with a bluetooth keyboard. Is this not the latest version of sdl? or is it just the port that is not supporting multiple surfaces? Reply to this email directly or view it on GitHub: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
|
I have found that the signed release version runs better then then the debug version. In fact there is a significant difference but the fade in fade out is still slower then it should be. Besides the the touch overlay buttons I a added I also changed the location where it writes the dosbox.conf file. I think this should be a permanent change so that we can modify the conf instead of being stuck with the default settings. I have not played with the settings yet but at least I have the option now(without having to hardcode) |
|
I did some work towards making fades faster, but it doesn't seem to have panned out. I implemented a new SDL video driver using OpenGL ES 2.0 and set up an actual palette texture to handle the changes, but in release mode the speeds are equivalent. Debug mode is much faster, but that's not much of a gain. |
|
Ya I forked the repos but I have not updated them yet. I will though.
|
|
I have updated my forks: https://github.com/a7omic -Changed default location of config file The toggle is more of a proof of concept and just the first building block of what I would rather implement but I have not had any time lately to work on this. I did not do a pull request though. I find it strange that you said release mode was slower then debug, I found the complete opposite when using the current build. |
|
I've seen the same more recently, release mode is much faster. I probably had something wrong in the setup. ----- Original Message ----- I have updated my forks: https://github.com/a7omic -Changed default location of config file The toggle is more of a proof of concept and just the first building block of what I would rather implement but I have not had any time lately to work on this. I did not do a pull request though. I find it strange that you said release mode was slower then debug, I found the complete opposite when using the current build. Reply to this email directly or view it on GitHub: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
Hey Jeremy,
Have you successfully exported a signed bar for dosbox and run in on you playbook? When I run in debug mode there are no issues but my signed bar file crashes in less then a second after the standard blackberry splash screen appears. I know I am not the only one that has had this issue either.
Are there any logs that I can check or can you think of anything for me to check in the code?
Thx,
W.
The text was updated successfully, but these errors were encountered: