BUG: Serna Free and "Serna: Critical Error" fo controller error

I'm blogging this here because I encountered this error with Serna Free XML Editor before, and when I went back to search for it on their forums it was nowhere to be found. This bug was found in the Serna Free 4.3 version, packaged as an RPM. It has taken me a good 5 hours to diagnose this issue in a user guide I was working on. I'll record my findings in a bug-style format. Hopefully it helps you diagnose this issue if you find it.

tl:dr

The solution for me was to ensure entities containing XML markup were not nested in tags like <literal> or similar XML markup. Even though my XML code was valid to DocBook 4.5, it seems Serna has a problem rendering this element combination in WYSIWYG mode.

If you choose an Entity file to store all your entity declarations (rather than declaring entities in each XML file comprising your book), you must ensure each XML file has a parameter entity in the DOCTYPE declaration of each XML file that points to the file. Serna needs this to parse entities correctly.

Read on for the full brain dump below and more info about the stuff I mentioned above.

Issue

Serna Free v4.3 (referred to as Serna from this point on) can not open a large XML file in "Open Normally" mode without crashing with an "fo controller" error.

Details


I have a guide that is over 200 (serna) pages long, and after adding some entities to replace long file paths, the guide would not open.

This problem started to present after replacing some file names with a local entity containing a full file path, complete with XML markup.

<!FILEPATH "<filename><replaceable>VERY</replaceable>/long/<replaceable>path&</replaceable>/to/the/config-file.xml</filename>">

I went to lunch while Serna was open and when I came back and tried to resume adding the local entities to the book, the Add Entity catalog would not display the local list of entities.

I closed Serna. That is when I found the problem in $Issue.

Serna would try to open the document and expand all sections, however it got to about (serna page) 71 and then the Serna: Critical Error displayed.

Troubleshooting

Level 1

I checked the following:

1. All XML files had correct external (parsed) parameter entity declarations in the DOCTYPE declaration [1]. Serna needs parameter entities declared in each file in the book, so it has access to the entity catalog file (saved as .ent) for the book.
2. The book was well-formed and valid.
3. The book built using a documentation build chain (in this case Publican).

All these items checked out.

Level 2

I opened the document in "Collapsed Mode" and manually expanded each Chapter and Section from the beginning until I got up to about page 65. Serna started to overwrite some graphics over the text in the WYSIWYG view. Serna then proceeded to crash at about (serna page) 70.

Level 3

I then removed Serna using the Fedora Package Manager, and then reinstalled Serna using the RPM provided on the Syntext website. I tried to open the same book again and saw the same results. This did not resolve the issue.

Resolution

I deduced that the problem only occurred after adding the Entities in bulk to the file. So I opened each file in a plain text editor (gedit) and searched for all the $FILEPATH; entities backtracked through the file and found that some of the entities were nested in &lt;literal> or other semantic XML tags.

<literal>

  $FILEPATH;

</literal>

So when Serna attempted to parse the XML combination, the Entity was expanded to:

<literal>
 &lt;filename><replaceable>VERY</replaceable>/long/<replaceable>path&</replaceable>/to/the/config-file.xml</filename>
</literal>

Serna seemed to have some difficulty rendering the WYSIWYG XSL for this element combination and therefore couldn't successfully paginate past this point. The structure is valid according to the DocBook Guide.

Summary

Ensure all files in your book contain the parameter entity for each file, and ensure entities containing XML markup as part of the entity *do not* get nested in semantic XML markup tags


[1] Parameter entities are declared in the DOCTYPE declaration of XML files to specify a local file that contains entity declarations. Refer to this page (scroll to bottom) for more info.

You have read this article Bug / Documentation / Serna / Syntext / XML with the title . You can bookmark this page URL https://azaquery.blogspot.com/2011/07/bug-serna-free-and-critical-error-fo.html. Thanks!

Multiple APK Support in Android Market

[This post is by Eric Chu, Android Developer Ecosystem. —Dirk Dougherty]

At Google I/O we announced our plans to add several new capabilities to help developers manage their products more effectively in Android Market. We’re pleased to let you know that the latest of those, multiple APK support, is now available. Multiple APK support is a new publishing option in Android Market for those developers who want extra control over distribution.

Until now, each product listing on Android Market has included a single APK file, a universal payload that is deliverable to all eligible devices — across all platform versions, screen sizes, and chipsets. Broad distribution of a single APK works very well for almost all applications and has the advantage of simplified product maintenance.

With multiple APK support, you can now upload multiple versions of an APK for a single product listing, with each one addressing a different subset of your customers. These APKs are complete, independent APKs that share the same package name, but contain code and resources to target different Android platform versions, screen sizes, or GL texture-compression formats. When users download or purchase your app, Android Market chooses the right APK to deliver based on the characteristics of the device.

When you upload multiple APK files, Android Market handles them as part of a single product listing that aggregates the app details, ratings, and comments across the APKs. All users who browse your app’s details page see the same product with the same description, branding assets, screenshots, video, ratings, and comments. Android Market also aggregates the app’s download statistics, reviews, and billing data across all of the APKs.

Multiple APK support gives you a variety of ways to control app distribution. For example, you could use it to create separate APKs for phones and tablets under the same product listing. You could also use it to take advantage of new APIs or new hardware capabilities without impacting your existing customer base.

To support this new capability, we’ve updated the Developer Console to include controls for uploading and managing APKs in a product listing — we encourage you to take a look. If you’d like to learn more about how multiple APK support works, please read the developer documentation. As always, please feel free to give us feedback on the feature through the Market Help Center.

You have read this article Android Market with the title . You can bookmark this page URL https://azaquery.blogspot.com/2011/07/multiple-apk-support-in-android-market_21.html. Thanks!

Debugging Android JNI with CheckJNI

[This post is by Elliott Hughes, a Software Engineer on the Dalvik team — Tim Bray]

Although most Android apps run entirely on top of Dalvik, some use the Android NDK to include native code using JNI. Native code is harder to get right than Dalvik code, and when you have a bug, it’s often a lot harder to find and fix it. Using JNI is inherently tricky (there’s precious little help from the type system, for example), and JNI functions provide almost no run-time checking. Bear in mind also that the developer console’s crash reporting doesn’t include native crashes, so you don’t even necessarily know how often your native code is crashing.

What CheckJNI can do

To help, there’s CheckJNI. It can catch a number of common errors, and the list is continually increasing. In Gingerbread, for example, CheckJNI can catch all of the following kinds of error:

• Arrays: attempting to allocate a negative-sized array.

• Bad pointers: passing a bad jarray/jclass/jobject/jstring to a JNI call, or passing a NULL pointer to a JNI call with a non-nullable argument.

• Class names: passing anything but the “java/lang/String” style of class name to a JNI call.

• Critical calls: making a JNI call between a GetCritical and the corresponding ReleaseCritical.

• Direct ByteBuffers: passing bad arguments to NewDirectByteBuffer.

• Exceptions: making a JNI call while there’s an exception pending.

• JNIEnv*s: using a JNIEnv* from the wrong thread.

• jfieldIDs: using a NULL jfieldID, or using a jfieldID to set a field to a value of the wrong type (trying to assign a StringBuilder to a String field, say), or using a jfieldID for a static field to set an instance field or vice versa, or using a jfieldID from one class with instances of another class.

• jmethodIDs: using the wrong kind of jmethodID when making a Call*Method JNI call: incorrect return type, static/non-static mismatch, wrong type for ‘this’ (for non-static calls) or wrong class (for static calls).

• References: using DeleteGlobalRef/DeleteLocalRef on the wrong kind of reference.

• Release modes: passing a bad release mode to a release call (something other than 0, JNI_ABORT, or JNI_COMMIT).

• Type safety: returning an incompatible type from your native method (returning a StringBuilder from a method declared to return a String, say).

• UTF-8: passing an invalid Modified UTF-8 byte sequence to a JNI call.

If you’ve written any amount of native code without CheckJNI, you’re probably already wishing you’d known about it. There’s a performance cost to using CheckJNI (which is why it isn’t on all the time for everybody), but it shouldn’t change the behavior in any other way.

Enabling CheckJNI

If you’re using the emulator, CheckJNI is on by default. If you’re working with an Android device, use the following adb command:

adb shell setprop debug.checkjni 1

This won’t affect already-running apps, but any app launched from that point on will have CheckJNI enabled. (Changing the property to any other value or simply rebooting will disable CheckJNI again.) In this case, you’ll see something like this in your logcat output the next time each app starts:

D Late-enabling CheckJNI

If you don’t see this, your app was probably already running; you just need to force stop it and start it again.

Example

Here’s the output you get if you return a byte array from a native method declared to return a String:

W JNI WARNING: method declared to return 'Ljava/lang/String;' returned '[B'
W              failed in LJniTest;.exampleJniBug
I "main" prio=5 tid=1 RUNNABLE
I   | group="main" sCount=0 dsCount=0 obj=0x40246f60 self=0x10538
I   | sysTid=15295 nice=0 sched=0/0 cgrp=default handle=-2145061784
I   | schedstat=( 398335000 1493000 253 ) utm=25 stm=14 core=0
I   at JniTest.exampleJniBug(Native Method)
I   at JniTest.main(JniTest.java:11)
I   at dalvik.system.NativeStart.main(Native Method)
I 
E VM aborting

Without CheckJNI, you’d just die via SIGSEGV, with none of this output to help you!

New JNI documentation

We’ve also recently added a page of JNI Tips that explains some of the finer points of JNI. If you write native methods, even if CheckJNI isn’t rejecting your code, you should still read that page. It covers everything from correct usage of the JavaVM and JNIEnv types, how to work with native threads, local and global references, dealing with Java exceptions in native code, and much more, including answers to frequently-asked JNI questions.

What CheckJNI can’t do

There are still classes of error that CheckJNI can’t find. Most important amongst these are misuses of local references. CheckJNI can spot if you stash a JNIEnv* somewhere and then reuse it on the wrong thread, but it can’t detect you stashing a local reference (rather than a global reference) and then reusing it in a later native method call. Doing so is invalid, but currently mostly works (at the cost of making life hard for the GC), and we’re still working on getting CheckJNI to spot these mistakes.

We’re hoping to have more checking, including for local reference misuse, in a future release of Android. Start using CheckJNI now, though, and you’ll be able to take advantage of our new checks as they’re added.

You have read this article Debugging / JNI with the title . You can bookmark this page URL https://azaquery.blogspot.com/2011/07/debugging-android-jni-with-checkjni_19.html. Thanks!