I am using N97 and Nokia 5530 for my application. More often whenever I install my application. I find this error. I have searched the internet and found a number of ways to solve this problem. I did use them such as check size of jar and the one written in jad and corrected it but still problem is not solved.
How can I remove this error in my build. Any help in this regard is highly appreciated.
I have read the stuff--- Unification of .jar and .jad files in a J2ME application --- but today devices and internet are much faster. Can't we ignore the creation of jad file.
EDIT
Following are jad and manifest attributes. I am using NetBeans 6.9 and Nokia S60 5th Edition SDK to generate and build the MIDlet.
jad attributes are as follows
Backkey: -11
LGE-MIDlet-Height: 400
LGE-MIDlet-Target-LCD-Height: 400
LGE-MIDlet-Target-LCD-Width: 240
LGE-MIDlet-Width: 240
LeftSoftKey: -6
MIDlet-1: MyAppName,/icon.png,com.main.MainMidlet
MIDlet-Jar-Size: 964642
MIDlet-Jar-URL: MyAppName.jar
MIDlet-Name: MyAppName
MIDlet-Permissions: javax.microedition.io.Connector.http
MIDlet-Touch-Support: true
MIDlet-Vendor: www.MyApp.com
MIDlet-Version: 1.4
MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: MIDP-2.0
Navi-Key-Hidden: true
Nokia-MIDlet-App-Orientation: portrait
Nokia-MIDlet-On-Screen-Keypad: no
RightSoftKey: -7
UseNativeTextButton: true
and Manifest attributes are
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.0
Created-By: 1.6.0_21-b06 (Sun Microsystems Inc.)
MIDlet-1: MyAppName,/icon.png,com.main.MainMidlet
MIDlet-Permissions: javax.microedition.io.Connector.http
MIDlet-Vendor: www.MyApp.com
Nokia-MIDlet-App-Orientation: portrait
LGE-MIDlet-Height: 400
Nokia-MIDlet-On-Screen-Keypad: no
MIDlet-Name: MyAppName
Navi-Key-Hidden: true
MIDlet-Touch-Support: true
LGE-MIDlet-Width: 240
MIDlet-Version: 1.4
Backkey: -11
LeftSoftKey: -6
UseNativeTextButton: true
LGE-MIDlet-Target-LCD-Height: 400
RightSoftKey: -7
LGE-MIDlet-Target-LCD-Width: 240
MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: MIDP-2.0
The only thing I can think of is that I usually see MIDlet-Jar-Size in the manifest, not in the jad.
Unfortunately, I never figured out how the build system managed to insert it in a compressed file (jars are basically zip files) and I don't know how to tell Netbeans to move the property from the jad to the manifest.
I was under the impression that if you ask Netbeans to generate a simple HelloWorld MIDlet and don't modify the ant script, MIDlet-Jar-Size ends up in the manifest.
I do think there is a relation between the property and the MIDlet being signed. It may act as a checksum.
Related
I have a Mac and just installed LaTeX and the editor Texmaker. To use the Arial font I installed it via MiKTeX Console. I also found out that by doing so, the files for the installed packages lay here:
"/Users/Mirko/Library/Application Support/MiKTeX/texmfs/install/tex/latex"
My problem is that the Editor (TeXMaker) still doesn't find the Arial-Font.
Here is my Code:
\documentclass[pdftex,openany,11pt,twoside,a4dutch]{report}
\usepackage{uarial}
\usepackage{csquotes}
\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{csquotes} % Setzen von Anführungsstrichen
\begin{document}
This is a test.
\end{document}
and here is the Error:
! LaTeX Error: File `uarial.sty' not found.Type X to quit or <RETURN> to proceed,or enter new name. (Default extension: sty)Enter file name:! Emergency stop.<read > \usepackage
But the folder arial and the file arial.sty are in the above mentioned folder.
In the MikTeX-Console I already entered the folder to Directories > Settings
I thankful for every help!
Thanks and greetings!
Here is the log-file from TexMaker:
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) (preloaded format=pdflatex 2019.10.27) 27 OCT 2019 13:34
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**test.tex
(./test.tex
LaTeX2e <2018-12-01>
(/usr/local/texlive/2019/texmf-dist/tex/latex/base/report.cls
Document Class: report 2018/09/03 v1.4i Standard LaTeX document class
(/usr/local/texlive/2019/texmf-dist/tex/latex/base/size11.clo
File: size11.clo 2018/09/03 v1.4i Standard LaTeX file (size option)
)
\c#part=\count80
\c#chapter=\count81
\c#section=\count82
\c#subsection=\count83
\c#subsubsection=\count84
\c#paragraph=\count85
\c#subparagraph=\count86
\c#figure=\count87
\c#table=\count88
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
)
! LaTeX Error: File `uarial.sty' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
<read *>
l.5 \usepackage
{csquotes}^^M
*** (cannot \read from terminal in nonstop modes)
Here is how much of TeX's memory you used:
221 strings out of 492616
2365 string characters out of 6129480
60608 words of memory out of 5000000
4231 multiletter control sequences out of 15000+600000
3940 words of font info for 15 fonts, out of 8000000 for 9000
1141 hyphenation exceptions out of 8191
21i,0n,22p,110b,36s stack positions out of 5000i,500n,10000p,200000b,80000s
! ==> Fatal error occurred, no output PDF file produced!
As you can see from the first line of the log file
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019)
texmaker is not using the miktex distribution for which you installed the uarial package, but a texlive distribution which seems to be also installed on your computer. In the long run it would be best to only have a single tex distribution on your computer to avoid such problems. For mac I would suggest to keep the texlive distribution and get rid of miktex, because texlive is used by most mac users and therefore well tested compared to miktex for mac.
Now you could force texmaker to use your miktex installation by modifying the texmaker preferences, but the easier way to use Arial in your document is to switch from pdflatex to xelatex or lualatex and directly use the arial font installed on your computer
% !TeX TS-program = xelatex
\documentclass[openany,11pt,twoside,a4dutch]{report}
\usepackage{fontspec}
\setmainfont{Arial}
\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}
\usepackage{csquotes}
\begin{document}
This is a test.
\end{document}
My NodeMCU program has gone in to infinite reboot loop.
My code is functionally working but any action I try to do, e.g. file.remove("init.lua") or even just =node.heap(), it panics and reboots saying: PANIC: unprotected error in call to Lua API (not enough memory).
Because of this, I'm not able to change any code or delete init.lua to stop automatic code execution.
How do I recover?
I tried re-flashing another version of NodeMCU, but it started emitting garbage in serial port.
Then, I recalled that NodeMCU had two extra files: blank.bin and esp_init_data_default.bin.
I flashed them at 0x7E000 and 0x7C000 respectively.
They are also available as INTERNAL://BLANK and INTERNAL://DEFAULT in the NodeMCU flasher.
This booted the new NodeMCU firmware, all my files were gone and I'm out of infinite reboot loop.
Flash the following files:
0x00000.bin to 0x00000
0x10000.bin to 0x10000
And, the address for esp_init_data_default.bin depends on the size of your module's flash.
0x7c000 for 512 kB, modules like ESP-01, -03, -07 etc.
0xfc000 for 1 MB, modules like ESP8285, PSF-A85
0x1fc000 for 2 MB
0x3fc000 for 4 MB, modules like ESP-12E, NodeMCU devkit 1.0, WeMos D1 mini
Then, after flashing those binaries format its file system (run "file.format()" using ESPlorer) before flashing any other binaries.
Downloads Link
I've just finished working through a similar problem. In my case it was end-user error that caused a need to forcibly wipe init.lua, but I think both problems could be solved similarly. (For completeness, my problem was putting a far-too-short dsleep() call in init.lua, leaving the board resetting itself immediately upon starting init.lua.)
I tried flashing new NodeMCU firmware, writing blank.bin and esp_init_data_default.bin to 0x7E000 and 0x7C000, and also writing 0x00000.bin to 0x00000 and 0x10000.bin to 0x10000. None of these things helped in my case.
My hardware is an Adafruit Huzzah ESP8266 breakout (ESP-12), with 4MB of flash.
What worked for me was:
Download the NONOS SDK from Espressif (I used version 1.5.2 from http://bbs.espressif.com/viewtopic.php?f=46&t=1702).
Unzip it to get at boot_v1.2.bin, user1.1024.new.2.bin, blank.bin, and esp_init_data_default.bin (under bin/ and bin/at/).
Flash the following files to the specified memory locations:
boot_v1.2.bin to 0x00000
user1.1024.new.2.bin to 0x010000
esp_init_data_default.bin to 0xfc000
blank.bin to 0x7e000
Note about flashing:
I used esptool.py 1.2.1.
Because of the nature of my problem, I was only able to write changes to the flash when in programming mode (i.e. after booting with GPIO0 held down to GND).
I found that I needed to reset the board between each step (else invocations of esptool.py after the first would fail).
Erased the flash. esptool.py --port <your/port> erase_flash
Then I was able to write a new firmware. I used a stock nodeMCU 0.9.5 just to isolate variables, but I strongly suspect any firmware would work at this point.
The only think that worked for me was python flash tool esptool in ubuntu, windows flashtool never deleted init.lua and reboot loop.
Commands (ubuntu):
git clone https://github.com/themadinventor/esptool.git
cd esptool
python esptool.py -h
ls -l /dev/tty*
nodemcu_latest.bin can be downloaded from github or anywhere.
sudo python esptool.py -p /dev/ttyUSB0 --baud 460800 write_flash --flash_size=8m 0 nodemcu_latest.bin
I have configured a private APT repository (using resources on internet like http://inodes.org/2009/09/14/building-a-private-ppa-on-ubuntu/) and I'm uploading for the first time my package containing the sources of my C++ application.
So reprepro repository is empty.
I use the following command in order to start the build:
sudo reprepro -V -b /srv/reprepro processincoming incoming
Then the build start, a lot of output is genearated and I can see that pbuilder is compiling the project source code and everything is fine. I can even find in the result/ folder debian packages etc...
But the build failed with a POST_BUILD_FAILED because it seems that pbuilder has changed the douane-testing_0.8.1-apt1.debian.tar.gz file and the md5 sum is now different as shown here:
File "pool/main/d/douane-testing/douane-testing_0.8.1-apt1.debian.tar.gz" is already registered with different checksums!
md5 expected: 97257ae2c5790b84ed7bb1b412f1d518, got: df78f88b97cadc10bc0a73bf86442838
sha1 expected: ae93c44593e821696f72bee4d91ce4b6f261e529, got: d6f910ca5707ec92cb71601a4f4c72db0e5f18d9
sha256 expected: c3fac5ed112f89a8ed8d4137b34f173990d8a4b82b6212d1e0ada1cddc869b0e, got: ebdcc9ead44ea0dd99f2dc87decffcc5e3efaee64a8f62f54aec556ac19d579c
size expected: 2334, got: 2344
There have been errors!
I don't understand why it is failing as when I compare the 2 packages (having those md5 sums) the content is strictly the same (I used a diff tool but no differences and no new or removed files).
The only thing I can see is that the archive from pbuild is bigger of 10 Bytes than the orginal one I have uploaded:
On my development machine, the file with the md5 97257ae2c5790b84ed7bb1b412f1d518 :
-rw-r--r-- 1 zedtux zedtux 2334 Feb 3 23:38 douane-testing_0.8.1-apt1.debian.tar.gz
On my server, the file with the md5 df78f88b97cadc10bc0a73bf86442838 :
-rw-r--r-- 1 root root 2344 Feb 5 00:58 douane-testing_0.8.1-apt1.debian.tar.gz
I have pbuild version 0.213 on my server.
What could be the reason of this behavior and how can I fix it ?
Edit
I'm suspecting an issue with the GPG key which looks missing and then files aren't signed so md5sum is different.
During the build process I have the following lines:
I: Extracting source
gpgv: Signature made Wed Feb 5 22:04:37 2014 UTC using RSA key ID 9474CF36
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./douane-testing_0.8.1-apt1.dsc
Edit 2
I have tried to find the command to create manually the .debian.tar.gz file.
The best I've found is the following:
tar cv debian | gzip --no-name --rsyncable -9 > douane-testing_0.8.1-apt1.debian.tar.gz
I don't get the same result than dpkg-source but I tried the same command on my server (I should at least have the same size) but it's not matching...
Could it be that Debian and Ubuntu aren't compressing the same way ?
Finally after some evenings of research I found the solution on launchpad.net !
Found the solution. By default pbuilder calls dpkg-buildpackage like so:
DEBBUILDOPTS="$DEBBUILDOPTS -rfakeroot"
dpkg-buildpackage -us -uc $DEBBUILDOPTS
That causes dpkg-buildpackage to rebuild the diff.gz and .dsc files. Add a -b in there, and it won't. It also means the resulting .changes file will only reference the .deb file. Which is what you want, I think.
The easy solution is to add a line to your .pbuilderrc:
DEBBUILDOPTS="-b"
My previous answer is alright but is not complete.
Then I had the issue that reprepro complains about the source tarball (.orig.tar.xz).
But it was normal as I wasn't doing the packages correctly.
I have written a bash script which I'm executing in VM for each Ubuntu series.
This script was always doing everything from scratch, and was using dh_make --createorig argument and here is the issue.
The correct way is to generate once (for example on Ubuntu precise) and then re-use the .orig.tar.xz file and no more use the --createorig argument of dh_make.
I hope this could help someone :-)
I've uploaded my app to google. It has been published. My main exp file was uploaded with app version code 2 and it still bears the same name. My main app is right now at version code 4 and is still using the main.2 exp file.
I've already tested the file with my app through debug.
I've created a test account and i'm signed in on the device with that account and tried downloading 20 minutes after creating that test account.
I believe my file size is correct too. I'm using the the size from the properties 155,630,535 bytes and set it to 155630535L. There is another one called as size on disk which I'm not using.
I've uploaded my apk over 12 hours ago.
Really don't know where I'm going wrong. The only thing I wonder about is my version name which is 1.13. Do I need to use this anywhere?
I'm having problems downloading my expansion files. Initially I was getting 'download failed because you may not have purchased this app'. Now after recompiling (export file) the apk file and uninstalling it and reinstalling it to my device, I've uploaded it to my publish account and now I get 'resources could not be found'. Please help...
ok. I've resolved my issues after a lot of struggling by myself.
First, it's the size of the file in bytes only and not the size of the file in bytes on the disk.
Secondly, they have moved the test account into settings. You need to create a test account.
Thirdly, the app needs to be saved in draft mode. The expansion files will not download while testing using the test account, if the app has been published.
I hope this will help someone.
Some helfull information for people that end up here in this post since there are some things that changed in the way apk expansions work and also if you are using Android Studio to make the libraries work.
NOTE 1
You can't use draft anymore as the link to get the expansion file won't be active yet. You have to upload a version to Alpha or Beta first with expansion file. (adding an expansion file is only possible from the second apk you upload and up) So make sure you see the apk expansion file listed when you click the details in the developer publish section under APK.
NOTE 2
If you are using android studio and want to make use of the downloader library don't just copy the package name and java files into your own app src directory. Import the downloader library in eclipse and choose export => gradle build files. Afterwards you can import the library as a module in android studio.
NOTE 3
Not sure of this but I also think it's neccesary to download the app atleast once through the play store and have access to it with the account on your test device. So if you are working with alpha create a google+ test group and add yourself or other test devices to it.
BTW
With these libraries it's pretty easy to implement the apk expansion download just make sure:
your activity (the one where you want to implement the downloading
of the expansion pack when the downloading has not been done
automatically) implements IDownloaderClient.
you set up the service & receiver and set them up in your manifest.
The BASE64_PUBLIC_KEY in the service class is correct. Upload the
first apk => look in Services and API's in the developer console
under your app => License code for this app.
This code is used to see if the expansion file can be found on the device:
boolean expansionFilesDelivered() {
for (XAPKFile xf : xAPKS) {
String fileName = Helpers.getExpansionAPKFileName(this, xf.mIsMain, xf.mFileVersion);
Log.i(TAG, "Expansion filename " +fileName);
if (!Helpers.doesFileExist(this, fileName, xf.mFileSize, false))
return false;
}
return true;
}
It uses the class XAPKS wich represents an expansion file, be it either a main or patch file, having a certain filesize(bytes) and associated with a apk version (the one it was first added in).
private static class XAPKFile {
public final boolean mIsMain; // true
public final int mFileVersion; //example 4
public final long mFileSize; //example 126515695L
// example => main expansion that was first introduced in apk version 4 and is 126515695 bytes in size
XAPKFile(boolean isMain, int fileVersion, long fileSize) {
mIsMain = isMain;
mFileVersion = fileVersion;
mFileSize = fileSize;
}
}
Its also quite easy to read movie files and other stuff directly from the expansion file using the zip tools that google has provided (com.android.vending.zipfile).
First get the expansionfile using the methods provided in the library, the paremeters are integers that represent your main expansion apk version (the apk version where the expansion pack you need was first added) and the patch apk version.
ZipResourceFile expansionFile = APKExpansionSupport.getAPKExpansionZipFile(context, APKX_MAIN_APK, APKX_PATCH_APK);
Video
For playing video directly from this zipresourcefile:
AssetFileDescriptor a = expansionFile.getAssetFileDescriptor(pathToFileInsideZip);
Now from this assetFileDescriptor you can get a FileDescriptor and use this in your mediaplayer, the correct syntax to get your mediaplayer to play the video also needs the second and third parameter.. Be it the startoffset and length you can get from the AssetFileDescriptor.
player.setDataSource(a.getFileDescriptor(), a.getStartOffset(), a.getLength());
Other
For all the other stuff (like images) you can just get an inputstream of the zipresourcefile:
expansionFile.getInputStream(pathToFileInsideZip);`
ALSO make sure you don't compress the videos in the zip for this to work!
for example not to compress .mp4 files:
zip -n .mp4 -r zipfile.zip . -x ".*" -x "*/.*"
I'm pretty new to using WinDbg, but recently my application started having issues, but only on Windows 7 machines (it runs fine the first time the PC is started but crashes or just disappears silently each time after).
I got the mdmp file, but find myself somewhat lacking on how best to extract the data I need from it. I got the following analysis (might be doing it wrong)...
Can anyone hopefully help shed some light on my issue or if I'm running the analysis incorrectly:
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/Star_exe/1_0_0_0/4dbad268/KERNELBASE_dll/6_1_7600_16385/4a5bdaae/e0434352/00009617.htm?Retriage=1
FAULTING_IP:
KERNELBASE!RaiseException+58
752d9617 c9 leave
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 752d9617 (KERNELBASE!RaiseException+0x00000058)
ExceptionCode: e0434352 (CLR exception)
ExceptionFlags: 00000001
NumberParameters: 5
Parameter[0]: 80070002
Parameter[1]: 00000000
Parameter[2]: 00000000
Parameter[3]: 00000000
Parameter[4]: 57af0000
PROCESS_NAME: Star.exe
ERROR_CODE: (NTSTATUS) 0xe0434352 - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xe0434352 - <Unable to get error code text>
EXCEPTION_PARAMETER1: 80070002
EXCEPTION_PARAMETER2: 00000000
EXCEPTION_PARAMETER3: 00000000
EXCEPTION_PARAMETER4: 0
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
MANAGED_STACK: !dumpstack -EE
No export dumpstack found
MANAGED_BITNESS_MISMATCH:
Managed code needs matching platform of sos.dll for proper analysis. Use 'x86' debugger.
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]
LAST_CONTROL_TRANSFER: from 57c03970 to 752d9617
FAULTING_THREAD: ffffffff
DEFAULT_BUCKET_ID: STACKIMMUNE
PRIMARY_PROBLEM_CLASS: STACKIMMUNE
BUGCHECK_STR: APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_WRONG_SYMBOLS
STACK_TEXT:
00000000 00000000 star.exe+0x0
SYMBOL_NAME: star.exe
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: star
IMAGE_NAME: Star.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4dbad268
STACK_COMMAND: ** Pseudo Context ** ; kb
FAILURE_BUCKET_ID: STACKIMMUNE_e0434352_Star.exe!Unknown
BUCKET_ID: APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_WRONG_SYMBOLS_star.exe
FOLLOWUP_IP: *** WARNING: Unable to verify timestamp for Star.exe
Star!.ctor+0 [C:\Users\Aj\Documents\Visual Studio 2010\Projects\Star\Star\ViewModels\ViewModelBase.cs # 22]
00360000 ?? ???
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/Star_exe/1_0_0_0/4dbad268/KERNELBASE_dll/6_1_7600_16385/4a5bdaae/e0434352/00009617.htm?Retriage=1
Followup: MachineOwner
---------
You may want to use this article as a starting point: SOS: It's Not Just an ABBA Song Anymore
It looks like your application is a .NET application, make sure you've got the right .NET Framework installed. When you load the sos.dll file into windbg, you may have to provide a full path. Also, you can set up access to the public microsoft symbol servers to help with some of your stack tracing. This article may help: Debugging Tools and Symbols: Getting Started. Make sure you've got the latest version of the debugging tools.
!analyze will give you some information about the fault, but not too much else. You should look at the first article to see what else is going on.
Posting some information about your application will also help people see if you are having a similar issue.
It looks like the fault is happening in your ViewModelBase.cs file. You may want to add some logging (using log4net or similar tool) to catch the exception and print out the stack trace. You can also hook into AppDomain.CurrentDomain.UnhandledException event (or the Application.DispatcherUnhandledException event for WPF applications) to catch anything that's getting thrown and printing out something to a log file. In this case, you won't need to resort to WinDbg to figure out what's going on.
Well after several weeks of searching (maybe more), it turns out that when using Trend Micro Corporate, XP to Server 2003 is fine, Vista and Windows 7 to 2003 is fine, and even XP/Vista to server 2008 is fine, but (and I have no idea why), when using Windows 7 and trying to run a network application using a UNC path in the shortcut, it blocks certain pieces of the network traffic for that application, and it does so sporadically and what seems to be without any sound logic. I can't say why as we never quite figured out what exactly the catalyst was for setting off Trend, but I do know that when we disabled Trend, all was back to normal (something I wished we tried sooner). We found that by mapping a drive to our share and changing our shortcuts on our users workstations to use the mapped drive rather than a UNC path, the issue was averted.
Hopefully no one else runs into this problem, but if they do, this will perhaps shed some light on the issue.
Thank you!
Aj