On Fri, 2008-02-15 at 23:49 -0500, Ted Guild wrote:
> Chris Frey <[EMAIL PROTECTED]> writes:
>
> > On Fri, Feb 15, 2008 at 04:14:46PM -0500, Ted Guild wrote:
> >> Although I would appreciate any pointers with opensync if there is
> >> a way to upload LDIF address books with btool or perhaps edit the
> >> address book in the tarball backup I'd be interested to know how.
> >
> > There is an "upldif" command line tool available with Barry that will
> > *replace* your address book with the contents of LDIF. Note the word
> > replace.
>
> Thanks, that helped get my address book started again. Sadly some
> numbers I think I only had in the phone before this mishap with RIM
> util.
>
> > gdb /path/to/msynctool /path/to/corefile
> >
> > This will likely give you a message stating that the core file does not
> > match, and which binary actually crashed. This is often "osplugin" from
> > opensync, which turns out to be:
>
> Core was generated by `msynctool --sync kaddr'
> Program terminated with signal 11, Segmentation fault.
> #0 0x00002b0c8ecdd000 in strlen () from /lib/libc.so.6
> (gdb) bt
> #0 0x00002b0c8ecdd000 in strlen () from /lib/libc.so.6
> #1 0x00002b0c97772899 in _block_match (attr=<value optimized out>,
> block=0x7268542f73250059 <Address 0x7268542f73250059 out of bounds>) at
> vformat.c:913
> #2 0x00002b0c97772941 in vformat_find_attribute (vcard=<value optimized
> out>, name=0x2b0c9b85fd48 "FN", nth=13,
> block=0x7268542f73250059 <Address 0x7268542f73250059 out of bounds>) at
> vformat.c:938
> #3 0x00002b0c9b85b31d in conv_vcard_to_xml (conv_data=0x608680,
> input=0x663cd0 "ð<f", inpsize=<value optimized out>,
> output=0x43805dc8, outpsize=0x43805dd4, free_input=0x43805dd0, error=0x0)
> at xml-vcard.c:505
> #4 0x00002b0c8e839241 in osync_converter_invoke (converter=0x643a90,
> change=0x663210, converter_data=0x608680, error=0x0)
> at opensync_convert.c:104
> #5 0x00002b0c8e839cc3 in osync_conv_convert_fn (env=0x640dc0,
> change=0x663210, target_fn=0x643540, fndata=0x0,
> extension_name=0x0, error=0x0) at opensync_convert.c:495
> #6 0x00002b0c8e83a40b in osync_change_convert_extension (env=0x640dc0,
> change=0x663210, targetformat=0x642f20,
> extension_name=0x0, error=0x0) at opensync_changecmds.c:366
> #7 0x00002b0c8e83a52e in osync_change_convert_to_common (change=0x663210,
> error=0x0) at opensync_changecmds.c:417
> #8 0x00002b0c8ea5886a in _new_change_receiver (engine=0x657090,
> client=<value optimized out>, change=0x663210)
> at osengine_engine.c:170
> #9 0x00002b0c8ea58c9b in engine_message_handler (message=0x662200,
> engine=0x657090) at osengine_engine.c:285
> #10 0x00002b0c8e83e8bd in _incoming_dispatch (source=<value optimized out>,
> callback=<value optimized out>,
> user_data=0x6417a0) at opensync_queue.c:107
> #11 0x00002b0c8e5a1eb4 in g_main_context_dispatch () from
> /usr/lib/libglib-2.0.so.0
> #12 0x00002b0c8e5a519d in ?? () from /usr/lib/libglib-2.0.so.0
> #13 0x00002b0c8e5a5497 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #14 0x00002b0c8e5c3864 in ?? () from /usr/lib/libglib-2.0.so.0
> #15 0x00002b0c901f13f7 in start_thread () from /lib/libpthread.so.0
> #16 0x00002b0c8ed3997d in clone () from /lib/libc.so.6
> #17 0x0000000000000000 in ?? ()
>
Interesting, I am getting almost the exact same
subset of information when I run gdb. The second column of numbers
seems to be different.
#0 0x00000037684795a0 in strlen () from /lib64/libc.so.6
#1 0x00002aaaaaf191c9 in _block_match (attr=<value optimized out>,
block=0x7268542f73250059 <Address 0x7268542f73250059 out of bounds>)
at vformat.c:913
#2 0x00002aaaaaf19271 in vformat_find_attribute (vcard=<value optimized
out>,
name=0x2aaaac9efb68 "FN", nth=13,
block=0x7268542f73250059 <Address 0x7268542f73250059 out of bounds>)
at vformat.c:938
#3 0x00002aaaac9eafed in ?? ()
from /usr/lib64/opensync/formats/xml-vcard.so
#4 0x0000003f30019343 in osync_converter_invoke ()
from /usr/lib64/libopensync.so.0
#5 0x0000003f30019db3 in osync_conv_convert_fn ()
from /usr/lib64/libopensync.so.0
#6 0x0000003f3001a4fb in osync_change_convert_extension ()
from /usr/lib64/libopensync.so.0
#7 0x0000003f3001a61e in osync_change_convert_to_common ()
from /usr/lib64/libopensync.so.0
#8 0x0000003f30c09fda in _new_change_receiver ()
from /usr/lib64/libosengine.so.0
#9 0x0000003f30c0a43d in ?? () from /usr/lib64/libosengine.so.0
#10 0x0000003f3001eb42 in ?? () from /usr/lib64/libopensync.so.0
#11 0x00000038c062eea3 in g_main_context_dispatch ()
from /lib64/libglib-2.0.so.0
#12 0x00000038c063219d in ?? () from /lib64/libglib-2.0.so.0
#13 0x00000038c06324aa in g_main_loop_run ()
from /lib64/libglib-2.0.so.0
#14 0x00000038c0650724 in ?? () from /lib64/libglib-2.0.so.0
#15 0x0000003769006407 in start_thread () from /lib64/libpthread.so.0
#16 0x00000037684d4b0d in clone () from /lib64/libc.so.6
I am running FC8 x86_64. I am using the evo2-sync and barry-sync
plugins. I built mine from the SRPM instead of the straigh source code.
I made a change to
./barry-0.11/opensync-plugin/configure.ac LINE:9
export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}:/usr/lib64/pkgconfig:
$prefix/lib64/pkgconfig:/usr/local/lib64/pkgconfig
So that the RPM would build.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Barry-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/barry-devel
