Ok,my prediction is right, this segfault is solved by disabling NLS (the use of gettext(). etc..)in glib. Yet then Bus Error comes: I know,it's mainly caused by the typecast for ARM has no same alignment style as x86.The question is: is there a way to fix this in the arm-gcc option other than rewrite the typecast statements into memcpy()?(There are huge amount of such statements in glib.). The -O0 option doesnot work. Rgrds. On Fri, Mar 18, 2011 at 11:52 AM, Shuxiang Lim <[email protected]>wrote:
> Hi,all,caution of the radioactive rays! > I feel rather frustrated though...Now I have ported libglib2.0 and its > deps(libintl,libiconv...) onto android as well as libspicec-glib.so and > snappy. > But when run,the snappy got only SEGFAULT and killed. > *#LD_LIBRARY_PATH=/data/local/lib ./snappy -h 192.168.1.31 -p 5900 -o > ahoo.ppm* > *[1] + Stopped (signal) LD_LIBRARY_PATH=/data/local/lib ./snappy -h > 192.168.1.31 -p 5900 -o ahoo.ppm > [1] Segmentation fault LD_LIBRARY_PATH=/data/local/lib ./snappy -h > 192.168.1.31 -p 5900 -o ahoo.ppm* > > Tracing the process,I found the SEGFAULT came from the > glib:g_object_new()!: > gtk/spice-session.c: > addr = g_object_new (G_TYPE_NETWORK_ADDRESS, "hostname", s->host, "port", > port, NULL); > -->libgobject:gobject/gtype.c > g_object_new()-->g_type_class_ref()-->type_class_init_Wm() > -->libgio:gio/gnetworkaddress.c > g_network_address_class_init()-->CRASSSSHHHH. > > Now I'm still tracing the bug... It may come from the i18n string ops, but > if other bug occurs in glib,the future is dim... For I really has no time > and energy to hack the arcane and exotic glib(or it's caused by the > incorrect use of glib method in spicec?).(forgive such adjectives,to me,it's > true) > I really yearn for the spicec in PURE C and Modularized: > 1.Offer the switch to disable (do not POSIX-likedly depend on) locale, > libiconv, libintl, sys/shm.h, pwd.h, pthread,i18n, wchar_t,regex,gettext,... > for none of them can be found in android! > 2. Be as far away as we can from the other libs like the > glib/gtk,pulseaudio/alsalib... > 3. Completely modularize spicec into libspicec and spicec (this is what I > am working for) > as the data layer and the UI layer to ease the porting. > > Is there any plan about these now? Can anybody help to do the step 1 or > step 2 above? > Or, the simplest: the way to safely turn off locale and i18n in glib? > Pardon my whining and wish me Goodluck! > And again I shall desperately curse Android and bless Meego! > Regards. > > > On Thu, Mar 10, 2011 at 9:07 AM, Shuxiang Lim <[email protected]>wrote: > >> >> That's true. But the audio output as well as the image output is unexposed >> or disabled for C/C++ apps in Android.So I plan to dwindle the work to >> implement the image first,if success, the audio work will be easy to follow. >> >> Regards. >> >> On Wed, Mar 9, 2011 at 6:22 PM, Attila Sukosd <[email protected]>wrote: >> >>> Could you maybe give access to other devs to aid the development? >>> >>> Rgrds, >>> >>> Attila >>> >>> >>> On Wed, Mar 9, 2011 at 11:18 AM, Shuxiang Lim <[email protected]>wrote: >>> >>>> Yep, I walked around this but to face more chored and nasty troubles in >>>> porting Pulseaudio lib, time limited, so I decided to DISABLE the >>>> audio(playback/record) channels first. Thus the porting of >>>> libspicec_glib.so >>>> is finished(along with all its dependences) and androidVNCViewer(whose UI >>>> will be peeled to become spicec's) proj. has been built: >>>> *#file libspicec_glib.so * >>>> libspicec_glib.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), >>>> dynamically linked, not stripped >>>> *#arm-eabi-readelf -d libspicec_glib.so * >>>> Dynamic section at offset 0x774a4 contains 27 entries: >>>> Tag Type Name/Value >>>> 0x00000001 (NEEDED) Shared library: [libc.so] >>>> 0x00000001 (NEEDED) Shared library: [libm.so] >>>> 0x00000001 (NEEDED) Shared library: >>>> [libpixman-1.so.0] >>>> 0x00000001 (NEEDED) Shared library: >>>> [libssl.so.1.0.0] >>>> 0x00000001 (NEEDED) Shared library: >>>> [libcrypto.so.1.0.0] >>>> 0x00000001 (NEEDED) Shared library: [libjpeg.so.62] >>>> 0x00000001 (NEEDED) Shared library: [libz.so] >>>> 0x00000001 (NEEDED) Shared library: >>>> [libglib-2.0.so.0] >>>> 0x00000001 (NEEDED) Shared library: >>>> [libgio-2.0.so.0] >>>> 0x00000001 (NEEDED) Shared library: >>>> [libgobject-2.0.so.0] >>>> 0x00000001 (NEEDED) Shared library: >>>> [libgmodule-2.0.so.0] >>>> 0x00000001 (NEEDED) Shared library: >>>> [libgthread-2.0.so.0] >>>> 0x00000010 (SYMBOLIC) 0x0 >>>> .... >>>> Now comes the last adventure of Native interfaces exposing and UI >>>> building! >>>> Regards. >>>> >>>> >>>> On Wed, Mar 9, 2011 at 3:57 PM, Shuxiang Lim <[email protected]>wrote: >>>> >>>>> Well, I think I may try the "--with-coroutine=gthread" in spice-gtk >>>>> configuring to walk around that... >>>>> >>>>> >>>>> On Wed, Mar 9, 2011 at 11:10 AM, Shuxiang Lim >>>>> <[email protected]>wrote: >>>>> >>>>>> Hi,I need help! >>>>>> Now I've managed to divided spicec-gtk into two parts >>>>>> libspicec.so(based on libpixman.so,libglib-2.0.so...No relation to X11 at >>>>>> all) and spicec(based on libspicec.so and libgtk.so...). And the glib2.0 >>>>>> porting to Android is also completed. But I'm blocked in compiling >>>>>> libspicec >>>>>> onto Android at the begining for the continuation.c uses the functions in >>>>>> <ucontext.h> :setcontext(),getcontext()..., which are some thread-related >>>>>> funcs as I know,and, definitely unsuprisingly, Android libc doesn't have >>>>>> them! Is there a way to drop or replace the use of such funcs? Or should >>>>>> I >>>>>> manually write setcontext from scratch? >>>>>> RGRDs. >>>>>> >>>>>> >>>>>> On Mon, Mar 7, 2011 at 5:14 PM, Alon Levy <[email protected]> wrote: >>>>>> >>>>>>> On Mon, Mar 07, 2011 at 09:08:28AM +0800, Shuxiang Lim wrote: >>>>>>> > Option 1: use spice-gtk with a gtk android backend >>>>>>> > a) compiling gtk for it would be possible. >>>>>>> > b) write a partial gtk backend, good enough for spice-gtk. >>>>>>> > c) no changes to spice-gtk. >>>>>>> > Yep,that's really a good hope,but it's another project(too huge >>>>>>> and far >>>>>>> > away for me now): >>>>>>> > Project:"GTK for Android.". So now I can use only the Android SDK >>>>>>> to finish >>>>>>> > the UI(the new native UI APIs in NDK is not reliable in versions). >>>>>>> >>>>>>> Yeah, I think you're right, I can't find anyone already working on >>>>>>> this by >>>>>>> simple web search. Maybe spice-gtk's non ui objects are dependent >>>>>>> only on >>>>>>> gobject / stuff that is easy to just drop in (ugly, but still more >>>>>>> maintainable >>>>>>> then basing your work on spicec, long term). >>>>>>> >>>>>>> > And also you've referred that "spicec is already platform >>>>>>> independent", >>>>>>> > that's true to Linux and Windows,but not to Android,for such >>>>>>> independence is >>>>>>> > based on the C++ independence over the os which cannot stand >>>>>>> through the >>>>>>> > JAVA UIed android.So there is no way to just add a subdir ./android >>>>>>> under >>>>>>> > spice/client along with ./x11 and ./windows. It should be a >>>>>>> combined proj. >>>>>>> > of C/C++ and Java. (That's why I hate Android and yearn for >>>>>>> Maemo/Meego.) >>>>>>> >>>>>>> Definitely easier to port to Maemo :) >>>>>>> >>>>>>> > Regards. >>>>>>> > >>>>>>> > On Fri, Mar 4, 2011 at 7:04 PM, Alon Levy <[email protected]> >>>>>>> wrote: >>>>>>> > >>>>>>> > > On Fri, Mar 04, 2011 at 06:21:19PM +0800, Shuxiang Lim wrote: >>>>>>> > > > Hi, friends, >>>>>>> > > > Thanks for your replies. It's definitely right till now >>>>>>> I've been >>>>>>> > > > working a tougher way compared to spice-gtk.And actually I've >>>>>>> considered >>>>>>> > > to >>>>>>> > > > steer my way to the latter in fear of the troublesome and >>>>>>> crippled C++ >>>>>>> > > > support in Android NDK:C is more "simple and safe" in Android >>>>>>> than C++. >>>>>>> > > > But,AFAIK,there is no gtk port for Android yet. And the biggest >>>>>>> obstacle >>>>>>> > > is >>>>>>> > > > the framework of Android:in its design,all UI should be done in >>>>>>> JAVA >>>>>>> > > powered >>>>>>> > > > by SKIA libs.Therefore the port of UI libs(GTK,etc) will be >>>>>>> choked by the >>>>>>> > > > I/O level because Android don't completely expose them at >>>>>>> all!(I once >>>>>>> > > > managed to port Xfbdev onto it,but that's not commercially >>>>>>> practical at >>>>>>> > > all, >>>>>>> > > > it's just a geeky trick maybe,an app in Android SHOULD NOT do >>>>>>> this.) Only >>>>>>> > > > the algorithm/data computing-related C/C++ libs are welcomed to >>>>>>> be the >>>>>>> > > JNI >>>>>>> > > > servants to JAVA UI apps in Android. >>>>>>> > > > You see, in such aspect, there is not too much diff between >>>>>>> the C++ >>>>>>> > > way >>>>>>> > > > and gtk way in the porting of UI part. >>>>>>> > > >>>>>>> > > I'm going to try to prove that wrong by grepping hoping it makes >>>>>>> sense, I >>>>>>> > > never >>>>>>> > > actually coded in gtk: >>>>>>> > > >>>>>>> > > $ git grep GObjectClass >>>>>>> > > gtk/channel-cursor.c: GObjectClass *gobject_class = >>>>>>> > > G_OBJECT_CLASS(klass); >>>>>>> > > gtk/channel-display.c: GObjectClass *gobject_class = >>>>>>> > > G_OBJECT_CLASS(klass); >>>>>>> > > gtk/channel-inputs.c: GObjectClass *gobject_class = >>>>>>> > > G_OBJECT_CLASS(klass); >>>>>>> > > gtk/channel-main.c: GObjectClass *gobject_class = >>>>>>> G_OBJECT_CLASS(klass); >>>>>>> > > gtk/channel-playback.c: GObjectClass *gobject_class = >>>>>>> > > G_OBJECT_CLASS(klass); >>>>>>> > > gtk/channel-record.c: GObjectClass *gobject_class = >>>>>>> > > G_OBJECT_CLASS(klass); >>>>>>> > > gtk/spice-audio.h: GObjectClass parent_class; >>>>>>> > > gtk/spice-channel.c: GObjectClass *gobject_class = >>>>>>> G_OBJECT_CLASS >>>>>>> > > (klass); >>>>>>> > > gtk/spice-channel.h: GObjectClass parent_class; >>>>>>> > > gtk/spice-gstaudio.c: GObjectClass *gobject_class = >>>>>>> > > G_OBJECT_CLASS(klass); >>>>>>> > > gtk/spice-pulse.c: GObjectClass *gobject_class = >>>>>>> G_OBJECT_CLASS(klass); >>>>>>> > > gtk/spice-session.c: GObjectClass *gobject_class = >>>>>>> > > G_OBJECT_CLASS(klass); >>>>>>> > > gtk/spice-session.h: GObjectClass parent_class; >>>>>>> > > gtk/spice-widget.c: GObjectClass *gobject_class = >>>>>>> G_OBJECT_CLASS(klass); >>>>>>> > > >>>>>>> > > otoh: >>>>>>> > > U playa:spice-gtk alon (master)$ git grep --name-only GdkWindow >>>>>>> > > gtk/spice-widget-cairo.c >>>>>>> > > gtk/spice-widget.c >>>>>>> > > >>>>>>> > > (if you grep Window you get false negatives because of the >>>>>>> compression >>>>>>> > > window). >>>>>>> > > >>>>>>> > > Anyway, this is a lame attempt to prove the gtk stuff that does >>>>>>> ui (read: >>>>>>> > > uses X) >>>>>>> > > is separated in the code/architecture level :) >>>>>>> > > >>>>>>> > > > So for me the shining light of spicec-gtk is not in "GTK" >>>>>>> but in "C". >>>>>>> > > I >>>>>>> > > > dare not to say I'm clear about every nook in spicec at all. My >>>>>>> best hope >>>>>>> > > is >>>>>>> > > > that the IO in spicec shall be straight and succinct ,the inner >>>>>>> > > > graphic/sound computing(decompress,etc) shall have NO relation >>>>>>> with upper >>>>>>> > > UI >>>>>>> > > > libs at all, so I can pipe the Finished image flow into UI >>>>>>> through JNI >>>>>>> > > > interfaces and direct the user input backward. (That's why I >>>>>>> can borrow >>>>>>> > > the >>>>>>> > > > UI from AndroidVNCViewer) >>>>>>> > > >>>>>>> > > Yeah, I think it is generally so, but again, it's so in spice-gtk >>>>>>> too, and >>>>>>> > > that's >>>>>>> > > our only future supported client (*). >>>>>>> > > >>>>>>> > > (*) plans do change. >>>>>>> > > > >>>>>>> > > > libspicec.so(do most jobs) >>>>>>> > > > <==finishedimages/audio>>===<<inputs==>spicec.java.ui(only UI) >>>>>>> > > > >>>>>>> > > > Am I right? Is there any design that will frustrate this in >>>>>>> spicec or >>>>>>> > > > spice-gtk? >>>>>>> > > >>>>>>> > > spicec is already separated at the platform level, since it uses >>>>>>> low level >>>>>>> > > libraries directly, unlike spice-gtk (X and GDI). So you would >>>>>>> basically >>>>>>> > > be adding a platform/android. >>>>>>> > > >>>>>>> > > In gtk I really haven't done android development, ever, at least >>>>>>> not in the >>>>>>> > > C level, but I was hoping: >>>>>>> > > Option 1: use spice-gtk with a gtk android backend >>>>>>> > > a) compiling gtk for it would be possible. >>>>>>> > > b) write a partial gtk backend, good enough for spice-gtk. >>>>>>> > > c) no changes to spice-gtk. >>>>>>> > > >>>>>>> > > Option 2 is of course to make spice-gtk also have platform >>>>>>> separation, >>>>>>> > > while >>>>>>> > > still using gtk/gobject for all stuff that would Just Work when >>>>>>> doing 1.a >>>>>>> > > (the >>>>>>> > > data structures, the signals, the macros, the introspection?). >>>>>>> > > >>>>>>> > > > Regards. >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > On Fri, Mar 4, 2011 at 4:36 PM, Alon Levy <[email protected]> >>>>>>> wrote: >>>>>>> > > > >>>>>>> > > > > On Fri, Mar 04, 2011 at 03:38:51PM +0800, Shuxiang Lim wrote: >>>>>>> > > > > > Hi all, >>>>>>> > > > > > I'm trying these days to port spicec into Android.But >>>>>>> it's a >>>>>>> > > rather >>>>>>> > > > > TOUGH >>>>>>> > > > > > way to go because the structure of spicec and android are >>>>>>> desperately >>>>>>> > > > > > inappropriate:the linux version of spicec is based on the >>>>>>> X11,which >>>>>>> > > is >>>>>>> > > > > not >>>>>>> > > > > > available in Android,thus the UI of spicec should be >>>>>>> rewritten from >>>>>>> > > > > > scratch...More troublesome is that the UI part and data >>>>>>> part in >>>>>>> > > current >>>>>>> > > > > >>>>>>> > > > > Haven't looked at your proposal below yet, but did you check >>>>>>> the >>>>>>> > > spice-gtk >>>>>>> > > > > work? maybe it is easier to start from that? are gtk >>>>>>> libraries >>>>>>> > > available on >>>>>>> > > > > android? not talking about X. spice-gtk has objects for >>>>>>> connection and >>>>>>> > > > > channels >>>>>>> > > > > that afaik don't do any output, that's separate from the >>>>>>> actual widget >>>>>>> > > that >>>>>>> > > > > uses X. Also, gtk 3 has backends - did anyone do a backend >>>>>>> for android? >>>>>>> > > > > >>>>>>> > > > > Since going forward we plan to ditch the spicec client, that >>>>>>> would be >>>>>>> > > > > really >>>>>>> > > > > preffered. Now that I see what you have planned it sounds >>>>>>> good, but >>>>>>> > > better >>>>>>> > > > > to use spice-gtk. >>>>>>> > > > > >>>>>>> > > > > of course that's not to say we won't love to see this working >>>>>>> anyway :) >>>>>>> > > > > >>>>>>> > > > > > spicec is entangled in the hierarchical system in C++! So >>>>>>> my plan is >>>>>>> > > > > this: >>>>>>> > > > > > first split the spicec into two parts,data and UI,transform >>>>>>> the data >>>>>>> > > part >>>>>>> > > > > > into libspicec.so;then rewrite the UI part in JAVA. >>>>>>> Besides, I should >>>>>>> > > > > also >>>>>>> > > > > > tinker some problems caused by the Crippled NDK C++ support >>>>>>> and the >>>>>>> > > Lamed >>>>>>> > > > > > bionic c lib in android . >>>>>>> > > > > > And now the first step is roughly done,hence the change >>>>>>> of the >>>>>>> > > spicec >>>>>>> > > > > > structure: >>>>>>> > > > > > From >>>>>>> > > > > > >>>>>>> > > |-->playback >>>>>>> > > > > > thread >>>>>>> > > > > > >>>>>>> > > |-->cursor >>>>>>> > > > > > thread >>>>>>> > > > > > spicec:spicec process（application process）-->main >>>>>>> thread->|-->*record >>>>>>> > > > > thread >>>>>>> > > > > > * >>>>>>> > > > > > >>>>>>> > > |-->inputs >>>>>>> > > > > > thread >>>>>>> > > > > > >>>>>>> > > |-->display >>>>>>> > > > > > thread >>>>>>> > > > > > To: >>>>>>> > > > > > ===========================> >>>>>>> > > > > > |-->libspicec.so:application >>>>>>> thread-->main >>>>>>> > > > > > thread------>| >>>>>>> > > > > > | >>>>>>> > > > > > | >>>>>>> > > > > > | |<--display >>>>>>> thread<--| >>>>>>> > > > > > | >>>>>>> > > > > > | |--->|<--cursor >>>>>>> > > > > > thread<---|<------------------| >>>>>>> > > > > > | | |<--inputs >>>>>>> thread<---| >>>>>>> > > > > > spicec:spicec process--->| | |<--playback >>>>>>> thread<-| >>>>>>> > > > > > | | >>>>>>> > > > > > | | >>>>>>> > > > > > | | >>>>>>> > > > > > <---------------------------------------------| >>>>>>> > > > > > | >>>>>>> > > > > > | >>>>>>> > > > > > | >>>>>>> > > > > > | >>>>>>> > > > > > |-->spicec:platform >>>>>>> > > > > > thread------------------------------>| >>>>>>> > > > > > >>>>>>> > > > > > The hierarchical relationship has been unleashed with one >>>>>>> > > thread(record >>>>>>> > > > > > channel) deleted and two new threads (app and platform) >>>>>>> created. The >>>>>>> > > > > first >>>>>>> > > > > > as the "data thread",the other as the "work thread" which >>>>>>> is driven >>>>>>> > > by >>>>>>> > > > > the >>>>>>> > > > > > signals from the first thread as well as its sub threads >>>>>>> and >>>>>>> > > requested to >>>>>>> > > > > do >>>>>>> > > > > > the UI-related work: >>>>>>> > > > > > >>>>>>> > > > > > platform thread：------------>blocked and waiting:-->job >>>>>>> > > > > > request-<--------------| >>>>>>> > > > > > | | >>>>>>> > > > > > | >>>>>>> > > > > > ^ | >>>>>>> > > > > > | >>>>>>> > > > > > | >>>>>>> > > > > > | | >>>>>>> > > > > > |<----------|-<-| >>>>>>> > > > > > | >>>>>>> > > > > > | | >>>>>>> > > > > > | >>>>>>> > > > > > platform thread over<----------if(job==die)<--| >>>>>>> send req. >>>>>>> > > blocked >>>>>>> > > > > > and waiting >>>>>>> > > > > > | ^ >>>>>>> | >>>>>>> > > > > > | >>>>>>> > > > > > | | >>>>>>> | >>>>>>> > > > > > ^ >>>>>>> > > > > > | | >>>>>>> | >>>>>>> > > > > > _________|_________ >>>>>>> > > > > > | | >>>>>>> | >>>>>>> > > > > > | app/plbk/cusor >>>>>>> > > > > > thd >>>>>>> > > > > > |<---job done----dojob()<--else--| | >>>>>>> |->go >>>>>>> > > on->| >>>>>>> > > > > > __________________ >>>>>>> > > > > > | | >>>>>>> > > > > > |------------------------------->feed back-->| >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > So the next work is to expose the native JNI interface in >>>>>>> platform >>>>>>> > > thread >>>>>>> > > > > to >>>>>>> > > > > > the UI written in Android SDK. I try to use the UI >>>>>>> > > > > > frame of AndroidVNCViewer in >>>>>>> > > > > > code.google.com/p/*android*-*vnc*-viewer/,then the work of >>>>>>> platform >>>>>>> > > > > > thread will be replaced by UI but the msg >>>>>>> > > > > > communication to libspicec will be remained. That's the >>>>>>> easiest way I >>>>>>> > > can >>>>>>> > > > > > envisage except rewriting all parts in spicec from scratch. >>>>>>> > > > > > It's tough too, for I have poor experiance in Java... >>>>>>> > > > > > Anyway, is there any other guy working on this? Is my >>>>>>> way >>>>>>> > > > > feasible??Any >>>>>>> > > > > > Ideas or help is appreciated. >>>>>>> > > > > >>>>>>> > > > > See above for ideas, don't read them as a criticism, I think >>>>>>> this is >>>>>>> > > > > fantastic >>>>>>> > > > > what you've done so far. I remember someone posting "we are >>>>>>> working on >>>>>>> > > > > andriod >>>>>>> > > > > in our spare time" post to spice-devel, please grep the >>>>>>> archive. >>>>>>> > > > > >>>>>>> > > > > Alon >>>>>>> > > > > >>>>>>> > > > > > Best regards. >>>>>>> > > > > >>>>>>> > > > > > _______________________________________________ >>>>>>> > > > > > Spice-devel mailing list >>>>>>> > > > > > [email protected] >>>>>>> > > > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > >>>>>>> > > > _______________________________________________ >>>>>>> > > > Spice-devel mailing list >>>>>>> > > > [email protected] >>>>>>> > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel >>>>>>> > > >>>>>>> > > >>>>>>> >>>>>>> > _______________________________________________ >>>>>>> > Spice-devel mailing list >>>>>>> > [email protected] >>>>>>> > http://lists.freedesktop.org/mailman/listinfo/spice-devel >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Spice-devel mailing list >>>> [email protected] >>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel >>>> >>>> >>> >> >
_______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
