FXP14x: Unfortunately, Instagram has stopped [SOLVED]

Okay, I had to touch something somewhere and since a few days ago switching to the camera tab in Instagram crashes the whole thing.

I was quite confident it has something with the face-facing camera broken in FXP but as a fix was promised for FXP148 I stayed on the patient side.

I thundered 148 this morning and while the camera flash is fixed there, the rest keeps as broken as my English.

Here's the important part of logcat:

I/ActivityManager(  362): START {flg=0x10000 cmp=com.instagram.android/.activity.MediaCaptureActivity u=0} from pid 9175
I/CameraService( 4185): Opening camera 1
W/ServiceManager( 4185): Permission failure: com.sonyericsson.permission.CAMERA_EXTENDED from uid=10057 pid=9175
I/caladbolg( 4185):  380936309 cald_camctrl.c                    (6713)  9289 P [SVR]  380936248 + Cald_CamCtrl_PowerUp
I/caladbolg( 4185):  381160583 cald_camctrl.c                    (7484)  9289 P [SVR]  381160522 + Cald_CamCtrl_FSM_Func_PowerUp
I/caladbolg( 4185):  381203338 cald_hal_qct.c                    (2789)  9289 P [HAL]  381203247 + Cald_Hal_Qct_If_PowerUp
I/caladbolg( 4185):  381208679 cald_hal_qct.c                    (2847)  9289 P [HAL]  381208648 - Cald_Hal_Qct_If_PowerUp (0)
I/caladbolg( 4185):  381218536 cald_camctrl.c                    (7563)  9289 P [SVR]  381218475 - Cald_CamCtrl_FSM_Func_PowerUp (0)
I/caladbolg( 4185):  381218933 cald_camctrl.c                    (6720)  9289 P [SVR]  381218902 - Cald_CamCtrl_PowerUp (0)
I/AwesomePlayer( 4185): setDataSource_l('/system/media/audio/ui/camera_click.ogg')
W/WVMExtractor( 4185): Failed to open libwvm.so
I/AwesomePlayer( 4185): setDataSource_l('/system/media/audio/ui/VideoRecord.ogg')
W/WVMExtractor( 4185): Failed to open libwvm.so
D/Camera  ( 9175): app passed NULL surface
I/caladbolg( 4185):  381951782 cald_capctrl.c                    (6128)  9291 P [CAP]  381951751 + Cald_CapCtrl_FSM_Func_StartPreview
I/caladbolg( 4185):  381954376 cald_hal_qct.c                    (2983)  9291 P [HAL]  381954345 + Cald_Hal_Qct_If_StartPreview
I/caladbolg( 4185):  382005187 cald_hal_qct.c                    (3042)  9291 P [HAL]  382005157 - Cald_Hal_Qct_If_StartPreview (0)
I/caladbolg( 4185):  382005432 cald_capctrl.c                    (6358)  9291 P [CAP]  382005432 - Cald_CapCtrl_FSM_Func_StartPreview
F/libc    ( 4185): Fatal signal 11 (SIGSEGV) at 0x00008f28 (code=1), thread 9298 (cam_conf)
I/DEBUG   (  132): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (  132): Build fingerprint: 'SEMC/MT11i_1254-2184/MT11i:4.0.4/4.1.B.0.431/UL5_3w:user/release-keys'
I/DEBUG   (  132): pid: 4185, tid: 9298, name: UNKNOWN  >>> /system/bin/mediaserver <<<
I/DEBUG   (  132): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00008f28
I/ActivityManager(  362): Process com.cyanogenmod.filemanager (pid 7528) has died.
I/DEBUG   (  132):     r0 2bb55c98  r1 00008e00  r2 2bb56800  r3 00000000
I/DEBUG   (  132):     r4 2bb608fc  r5 2bb1892c  r6 2bb54f50  r7 2d3469cc
I/DEBUG   (  132):     r8 2d346a58  r9 2d346a5c  sl ffffffff  fp 2d346c80
I/DEBUG   (  132):     ip 2bb1897c  sp 2d3469c8  lr 2bb0dc5b  pc 2bb08578  cpsr 00010030
I/DEBUG   (  132):     d0  0000000000000000  d1  0000000000000000
I/DEBUG   (  132):     d2  0000000000000000  d3  0000000000000000
I/DEBUG   (  132):     d4  0000000001e00000  d5  0000000000000000
I/DEBUG   (  132):     d6  0007080000000000  d7  3f8000003f800000
I/DEBUG   (  132):     d8  0000000000000000  d9  0000000000000000
I/DEBUG   (  132):     d10 0000000000000000  d11 0000000000000000
I/DEBUG   (  132):     d12 0000000000000000  d13 0000000000000000
I/DEBUG   (  132):     d14 0000000000000000  d15 0000000000000000
I/DEBUG   (  132):     d16 3a64696f72646e61  d17 7265676775626564
I/DEBUG   (  132):     d18 bfe0000000000000  d19 0000000000000000
I/DEBUG   (  132):     d20 0000000000000000  d21 0000000000000000
I/DEBUG   (  132):     d22 0000000000000000  d23 0000000000000000
I/DEBUG   (  132):     d24 3ff55d890c229271  d25 3fd8000000000000
I/DEBUG   (  132):     d26 400170a260000000  d27 40020307a0000000
I/DEBUG   (  132):     d28 4003ba2980000000  d29 400150da20000000
I/DEBUG   (  132):     d30 4003ba2980000000  d31 40055815a0000000
I/DEBUG   (  132):     scr 20000012
I/DEBUG   (  132): 
I/DEBUG   (  132): backtrace:
I/DEBUG   (  132):     #00  pc 00045578  /system/lib/liboemcamera.so (vfe_cmd_sharpnessscale+27)
I/DEBUG   (  132):     #01  pc 0004ac57  /system/lib/liboemcamera.so (vfe_util_update_asf_5x5+30)
I/DEBUG   (  132):     #02  pc 0004af9b  /system/lib/liboemcamera.so (vfe_util_sharpness_afilter+2)
I/DEBUG   (  132):     #03  pc 00040701  /system/lib/liboemcamera.so (vfe_process_VFE_ID_SOF_ACK+44)
I/DEBUG   (  132):     #04  pc 0003d06b  /system/lib/liboemcamera.so (vfe_proc_vfe_msg+74)
I/DEBUG   (  132):     #05  pc 0000c77d  /system/lib/liboemcamera.so (config_proc_vfe_event_message+12)
I/DEBUG   (  132):     #06  pc 0000c43b  /system/lib/liboemcamera.so (cam_conf+314)
I/DEBUG   (  132):     #07  pc 000130d4  /system/lib/libc.so (__thread_entry+48)
I/DEBUG   (  132):     #08  pc 0001283c  /system/lib/libc.so (pthread_create+180) 

Apparently the things crashes right after trying to open camera 1.
Unlike the rest of the civilized world, the computing area starts numbering with zero, so there's no doubt Instagram is trying to use the second (implying less important) camera - the face-facing one we already know is broken!

Cause found, how about the fix?

I suppose I could just clean the app's settings, but that's a too crude a measure for a 21st century gentleman.

A bit of searching reveals the file

/data/data/com.instagram.android/shared_prefs/com.instagram.android_preferences.xml 

sports a very interesting line:

<string name="pref_camera_id_key">1</string>

Flip the 1 to a zero:

<string name="pref_camera_id_key">0</string>

and viola!

 

 ... eh, voilà!

This fixed it.

And a baby

About 4-5 months after the first eggs were laid and two months after her mother died, baby Phyllium biocculatum was born today. We named her Járinka.

It's a boy!

I'm not sure I mentioned it but we happen to keep about thirty phasmids of the Extatosoma tiaratum species. All of them are the posthumous offspring of a single mother - she died a year and something ago and the first ones hatched a half year ago.
Since the eggs weren't fertilized, all of them were supposed to be females, but nature has its ways ... When a phasmid individual has two sexual (X) chromosomes, it becomes a female. If it has only one it becomes a male. In this rare case something went wrong during the mitosis, the X chromosome didn't duplicate and the boy was born.

We noticed his unusual look - very few thorns, longer antennae, slim, almost green in colour, but it was only in the penultimate instar I took a picture of him:

Since then it grew a pair of wings and the antennae are even longer. Also he's mating with his sisters (ugh!) every now and then.

Boost regression tests with stdcxx4

Boost documentation describes nicely how to run regression tests, but when I tried to follow it on Solaris I encountered some caveats.
First of all, the testsuite assumes that one would want to build the bootstrap toolset with gcc and fails miserably on a system without it. The solution is to use the '--pjl-toolset=sun' option to run.py.

Second, I wanted to use the stdcxx4 Apache library instead of stlport4. I tried to add stdcxx4 as a new platform to boost, but it turned out to be more and more complicated so in the end I followed an advice from the boost community and just created ~/user-config.jam with this contents, to force use of stdcxx4:
using sun : : : -library=stdcxx4 -library=stdcxx4 ;

But it was still not enough, the script trying to build process_jam_log mixes the user flags and the default ones so the build was failing. A workaround:
$ cd tools_bb
$ svn diff
Index: tools/sun.jam
===================================================================
--- tools/sun.jam       (revision 81173)
+++ tools/sun.jam       (working copy)
@@ -20,7 +20,7 @@

 feature.extend stdlib : sun-stlport ;
 feature.compose sun-stlport
-    : -library=stlport4 -library=stlport4
+    : -library=stdcxx4 -library=stdcxx4

Step by step instructions:
$ wget http://svn.boost.org/svn/boost/trunk/tools/regression/src/run.py
$ export PATH=/export/home/tester/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/bin:$PATH
$ echo "using sun : : : -library=stdcxx4 -library=stdcxx4 ;" > ~/user-config.jam
$ python run.py --runner=Solaris 11.1-Studio-stdcxx4 --toolsets=sun --pjl-toolset=sun --local=/home/tester/Downloads/boost_1_51_0.tar.bz2
...
wait till tools_bb is checked out and hit Ctrl-C
...
$ vi tools_bb/tools/sun.jam
$ python run.py --runner=hajma --toolsets=sun --pjl-toolset=sun --local=/home/tester/Downloads/boost_1_51_0.tar.bz2

The results are upladed to http://www.boost.org/development/tests/trunk/developer/summary.html

[SOLVED] Unfortunately, Clock has stopped

When I upgraded my xperia ray from CM7 to CM9(FXP128), I was greeted by the message 'Unfortunately, Clock has stopped' whenever the phone started and anytime I touched the Clock widget. Apart from being annoying it meant I couldn't set my alarms so this became a priority one issue :-)

I opened the Terminal Emulator and typed:

$ su 
# logcat

Then I held 'Volume down' (a.k.a. Ctrl) and 'c' to stop the output. I scrolled a bit up in the output and found a line that said:

E/SQLiteOpenHelper( 5231): Couldn't open alarms.db for writing (will try read-only): E/SQLiteOpenHelper( 5231): android.database.sqlite.SQLiteException: Can't downgrade database from version 7 to 5

OK, so this is where it's breaking. I wasn't really interested in finding out what should the proper combination of ownership/permissions for the file as I didn't really trust it would end just here, downgrading database version offers a range of situations that can go wrong. And since I don't really care for my past alarm clock times, I got rid of the old database:

# cd /data/data/com.android.deskclock/databases 
# mv alarms.db alarms.db.bak 

Problem solved.

Fixing android_winusb.inf for Xperia ray

I'm in the process of getting root access to my new phone. I followed the steps at     http://unlockbootloader.sonymobile.com/instructions, but I got stuck at step 13. Windows would not accept the android_winusb.inf file I downloaded from Sony.
I used USBView to find out if the Vendor ID and Product ID fit to the numbers in the inf file, but did not find a problem there. Then I noticed that while all the other entries are present in both
[Google.NTx86] and [Google.NTamd64] sections, "; SonyEricsson" is missing in the latter. And the OS is actually the 64 bit version ...
After copying the %SingleAdbInterface%, %CompositeAdbInterface%, %SingleBootLoaderInterface% entries under [Google.NTamd64] Windows finally accepted the driver.

Just a side note to step 15, the fastboot.exe is located under 'platform-tools', not 'tools'.

One step closer to bricking the phone!

(fresh) Octave on Solaris

I've joined the online Machine Learning class offered by Coursera/Stanford University. The class uses GNU Octave as the primary programming tool and since it's not part of my OS and CSW only ships an ages old version, I had to update the spec (and a bunch of dependencies) and build it myself.
The binary package for Solaris 11 can be installed by:

pkg set-publisher -p http://pkg.opensolaris.cz/osol

pkg install SFEoctave SFExblas

The spec file is part of the SFE project.

Digikam 2.5.0

Digikam 2.5.0 now builds on S11 with Studio. It even starts up! :-)
But then it crashes somewhere in libkexiv2 when loading photos. That should be easy to track and fix though.
One step closer to usable desktop...

LEGO Aero Shredder build Instructions

We happen to have a couple of LEGO PowerMiners* sets. Some of them can be combined to produce more advanced machines, one just has to download the instructions from lego website.
In our case we wanted to build the Aero Shredder from the 8960 and 8958 sets.

However to my unpleasant surprise I found out that Lego not only discontinued the PowerMiners series - they also erased all documentation as well as user forums related to it.

Upset with this disgusting behavior I sent the lego support people a polite but urging e-mail and got a link for the instructions. So if you're looking for it, here it is.

(In case the link goes dead drop me an e-mail and I'll upload the pdf somewhere)


* This series is a slight variation on the discovery of America. Courageous scientists discover an underground world rich on resources (crystals). However the natives (rock monsters) stand in the way, so the holocaust begins.

KDE 4.8 RC2 on Solaris 11

Finally I found some motivation to debug the broken login to KDE. At first I got distracted by noticing most of plasma applets were crashing and I thought it might be related. I noted some familiar functions when debugging that and the deja-vu feeling started to grow. Indeed, I traced this Studio bug just a few weeks ago and even pushed a workaround to our Qt - but forgot to turn it on!

However that was a red herring, as I was still unable to login.

While I was inside plasma I fixed the remaining broken applet and started doing what I should have done from the beginning - analyzing the problem.

I saw that when the login stopped progressing, there was the kwapper4 process fully occupying one of the cores. The hotuser DTrace script told me it spent all the time inside the getDisplay() function. I then attached dbxtool and saw that it's looping these two lines:

   while((i = strchr(result, ':')))
     *i = '_';

That was weird. I started checking the documentation of strchr to see if there might be some difference between its behavior on Linux and Solaris and found nothing. Then I noticed that the code behaves correctly when I remove all the build options and after a handful of iterations I had the culprit - -xbuiltin=%all ... As the Studio documentation says - "Note that these substitutions can cause the setting of errno to become unreliable. If your program depends on the value of errno, avoid this option." and that's exactly what was happening. 

I removed the option from the whole kde-solaris repository, as it's probably only safe to use when one has the code under full control, which is not our case.

Now I'm able to log into KDE again:

Since KDE 4.8 will be released within several hours, I'll wait with publishing the binary packages

for the final release.

Kindle

It's about six months since I got myself a Kindle 3 and I have to say I'm very happy with this device. I read mostly English books and I just started with French ones.

The cool thing when reading stuff that's not in my mother tongue is that it does not feel like a complete waste of time, even when it's just a shallow entertaining title :-)

Here's the list of books I've finished so far:
Jerry Ahern: Survivalist: Total War, The Nightmare Begins, The Quest, The Doomsayer, The Web, The Savage Horde, The Prophet, The End Is Coming, Earth Fire
Alfred Assolant: Aventures merveilleuses mais authentiques du capitaine Corcoran
Tom Clancy: Rainbow Six
Arthur Conan Doyle: The Adventures of Sherlock Holmes
Charles Dickens: A Christmas Carol
Alexandre Dumas: Le comte de Monte-Christo Tome I
Frederick Forsyth: The Dogs of War, SSN
Thomas More: Utopia
Sax Rohmer: The Insidious Dr. Fu Manchu
Lemony Snicket: A series of unfortunate events: The Bad Beginning, The Reptile Room, The Wide Window, The Miserable Mill, The Austere Academy, The Ersatz Elevator, The Vile Village, The Hostile Hospital
Jules Verne: Robur le Conquerant