Menu
▾
▴
opensync-users
|
From: A. <rem...@ya...> - 2006-01-09 18:35:25
|
Hello
I had a SIGSEV during my first sync between evo2 and the file-sync
plugin.
My investigation sofar shows that it is related to the presence of
non-utf8 characters in the stuff sent by evo2.
in a first case, I was able to pinpoint the problem on the description
and I just removed the description of the event (see trace 1). It seems
that by updating the event, I changed something and it was better.
I had another problem, similar. see trace 2.
Looks like my problems are related to old entries, so I will purge evo2
to make sure I don't have the problem anymore. But it would be cool to
ensure that a SIGSEV cannot arise.
thus ...
I did a gdb session to understand where exactly was the SIGSEV. see
trace 3.
It seems that when vformat is creating a list of attributes that is not
valid, the function vcal_parse_attributes is not handling them well.
Using a for loop is maybe not a good idea in that function since there
are other location where the variable a is modified.
Regards
remyA
PS: trying to provide a diff later this night.
trace 1:
--------
[1136825381.689302]
Input vcal is:
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
ATTENDEE;CN=3DR=C3=A9my Amouroux;ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE;
PARTSTAT=3DACCEPTED:MAILTO:re...@am...
ORGANIZER:MAILTO:va...@am...
DTSTART:20050726T053000Z
DTEND:20050726T053000Z
TRANSP:OPAQUE
SEQUENCE:0
UID:
040000008200E00074C5B7101A82E0080000000070D7AE8F808CC50100000000000000001=
0
0000008C05F5F3D72E3B4C9A3BC7FBF434B6CD
DTSTAMP:20050719T144024Z
DESCRIPTION:Quand : mardi 26 juillet 2005 07:30-07:30 (GMT+01:00)
Bruxelles\, Copenhague\, Madrid\, Paris.\n\n*~*~*~*~*~*~*~*~*~*\n\nSi
tu
pouvais =C3=83=C2=AAtre l=C3=83 ce serait bien\n
SUMMARY:ATEc verification de la toiture Mr Domenec
PRIORITY:5
CLASS:PUBLIC
X-MICROSOFT-CDO-REPLYTIME:20050719T153821Z
CREATED:20050719T153821
LAST-MODIFIED:20050719T153821
END:VEVENT
END:VCALENDAR
[1136825381.689552]
Creating xml doc
[1136825381.689615]
parsing attributes
[1136825381.689674]
>>>>>>> vcal_parse_attributes(0xb6b51108, 0xac99ea8)
[1136825381.689734]
>>>>>>> vcal_handle_attribute(0xac94b80, 0xac99ea8, 0xac99cf0:PRODID)
[1136825381.689793]
Hook is: 0x1
[1136825381.689851]
<<<<<<< vcal_handle_attribute: Ignored
[1136825381.689910]
>>>>>>> vcal_handle_attribute(0xac94b80, 0xac99ea8, 0xac99f10:VERSION)
[1136825381.689969]
Hook is: 0x1
[1136825381.690027]
<<<<<<< vcal_handle_attribute: Ignored
[1136825381.690086]
>>>>>>> vcal_handle_attribute(0xac94b80, 0xac99ea8, 0xac9aaa8:METHOD)
[1136825381.690144]
Hook is: 0xdb9c3c
[1136825381.690200]
Handling method attribute
[1136825381.690264]
<<<<<<< vcal_handle_attribute
[1136825381.690330]
>>>>>>> vcal_parse_attributes(0xb6b510c8, 0xac9afb8)
[1136825381.690389]
<<<<<<< vcal_parse_attributes: Done
(log file ended her)
trace 2
-------
[1136826678.223093]
Input vcal is:
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
ATTENDEE;CN=3DR=C3=A9my Amouroux;ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE;
PARTSTAT=3DACCEPTED:MAILTO:rem...@ke...
ORGANIZER:MAILTO:va...@am...
DTSTART:20050922T060000Z
DTEND:20050922T080000Z
TRANSP:OPAQUE
SEQUENCE:0
UID:
040000008200E00074C5B7101A82E0080000000010E4575FC9AFC50100000000000000001=
0
000000B6F0CDF8F87227418E1C2A0DBE2BD607
DTSTAMP:20050902T121947Z
DESCRIPTION:Quand : jeudi 22 septembre 2005 08:00-10:00 (GMT+01:00)
Bruxelles\, Copenhague\, Madrid\, Paris.\n\n*~*~*~*~*~*~*~*~*~*\n\nTMV
St
Egreve 04/76/75/21/34\n\n\n\n
SUMMARY:Depannage Volet Budendorf
PRIORITY:5
CLASS:PUBLIC
X-MICROSOFT-CDO-REPLYTIME:20050902T135144Z
CREATED:20050902T135144
LAST-MODIFIED:20050902T135144
END:VEVENT
END:VCALENDAR
[1136826678.223346]
Creating xml doc
[1136826678.223411]
parsing attributes
[1136826678.223469]
>>>>>>> vcal_parse_attributes(0xb6b36108, 0xb1d915b8)
[1136826678.223529]
>>>>>>> vcal_handle_attribute(0xb1d8afb8, 0xb1d915b8,
0xb1d92110:PRODID)
[1136826678.223632]
Hook is: 0x1
[1136826678.223691]
<<<<<<< vcal_handle_attribute: Ignored
[1136826678.223750]
>>>>>>> vcal_handle_attribute(0xb1d8afb8, 0xb1d915b8,
0xb1d92130:VERSION)
[1136826678.223811]
Hook is: 0x1
[1136826678.223868]
<<<<<<< vcal_handle_attribute: Ignored
[1136826678.223927]
>>>>>>> vcal_handle_attribute(0xb1d8afb8, 0xb1d915b8,
0xb1d91540:METHOD)
[1136826678.223989]
Hook is: 0xe3dc3c
[1136826678.224046]
Handling method attribute
[1136826678.224111]
<<<<<<< vcal_handle_attribute
[1136826678.224176]
>>>>>>> vcal_parse_attributes(0xb6b360c8, 0xb1d92510)
[1136826678.224233]
<<<<<<< vcal_parse_attributes: Done
trace3:
------
Received a entry 20050525T023411Z-5011-100-1-5@remya with data of size 4
from member 1. Changetype ADDED
** (process:12799): WARNING **: invalid utf8 passed to VFormat. Limping
along.
** (process:12799): WARNING **: vcard ended without END:VCARD
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1229993040 (LWP 12804)]
0x003fcf3e in vcal_parse_attributes (hooks=3D0xb1624d58, table=3D0xb1624a=
b0,
paramtable=3D0xb1624ab0, attributes=3D0xb6afc108, root=3D0xb162c240)
at xml-vcal.c:676
676 for (a =3D *attributes; a; a =3D a->next) {
(gdb) print a
$1 =3D (GList *) 0x0
(gdb) print attributes
$2 =3D (GList **) 0xb6afc108
(gdb) print *attributes
$3 =3D (GList *) 0xb16233f8
(gdb) print *attributes-next
No symbol "next" in current context.
(gdb) print *attributes->next
$4 =3D {data =3D 0xb162b498, next =3D 0xb1623428, prev =3D 0xb16233f8}
(gdb) print *attributes->next->next
$5 =3D {data =3D 0xb162bfa8, next =3D 0xb1623440, prev =3D 0xb1623410}
(gdb) print **attr
Structure has no component named operator*.
(gdb) print *attr
$6 =3D {group =3D 0x0, name =3D 0xb16280b8 "BEGIN", params =3D 0x0, value=
s =3D
0xb1623434, decoded_values =3D 0xb1623458, encoding =3D VF_ENCODING_RAW,
encoding_set =3D 0}
(gdb) print *attr->values
$7 =3D {data =3D 0xb162b618, next =3D 0x0, prev =3D 0x0}
(gdb) print *attr->values->data
Attempt to dereference a generic pointer.
(gdb)
--=20
E-mail : Rem...@ya...
Yahoo Architecture Europe (http://www.yahoo.com/)
Yahoo Id: kelkooremya
|
|
From: A. <rem...@ya...> - 2006-01-11 09:33:16
|
Here is what I've done so far.
I applied the diff from DIFF 1 on
opensync/formats/vformats-xml/xml-vcal.c in order to avoid the SIGSEV.
Then I restarted the sync, and I got the TRACE 1.
This time, the call to vcal_parse_attributes is finishing correctly but
I got a very short xml out of it.
So, I decided to try something to get more xml.
Thus, the diff number 2, getting to the trace number 2.
In term of xml, it's a lot better.
But naturally, now I have another problem related to the following
message, I got on the error output.
(process:6753): GLib-CRITICAL **: g_hash_table_lookup: assertion
`hash_table !=3D NULL' failed
** ERROR **: file opensync_member.c: line 1206
(osync_member_commit_change): assertion failed: (change)
aborting...
will try to find what it means later (but if someone knows already,
thanks for the input :-)
regards
RemyA
DIFF 1:
[amourouxr@remya opensync]$ svn diff formats/vformats-xml/xml-vcal.c
Index: formats/vformats-xml/xml-vcal.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- formats/vformats-xml/xml-vcal.c (r=C3=A9vision 778)
+++ formats/vformats-xml/xml-vcal.c (copie de travail)
@@ -672,8 +672,8 @@
{
osync_trace(TRACE_ENTRY, "%s(%p, %p)", __func__, attributes,
root);
- GList *a =3D NULL;
- for (a =3D *attributes; a; a =3D a->next) {
+ GList *a =3D *attributes;
+ while (a) {
VFormatAttribute *attr =3D a->data;
if (!strcmp(vformat_attribute_get_name(attr), "BEGIN"))
{
@@ -707,6 +707,11 @@
return;
} else
vcal_handle_attribute(table, paramtable, root,
attr);
+
+ // time to "increment"
+ if(a) {
+ a =3D a->next;
+ }
}
osync_trace(TRACE_EXIT, "%s: Done", __func__);
}
DIFF 2:
[amourouxr@remya opensync]$ svn diff formats/vformats-xml/vformat.c
Index: formats/vformats-xml/vformat.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- formats/vformats-xml/vformat.c (r=C3=A9vision 778)
+++ formats/vformats-xml/vformat.c (copie de travail)
@@ -496,10 +496,11 @@
VFormatAttribute *attr;
/* first validate the string is valid utf8 */
- if (!g_utf8_validate (buf, -1, (const char **)&end)) {
+ while (!g_utf8_validate (buf, -1, (const char **)&end)) {
/* if the string isn't valid, we parse as much as we can
from it */
g_warning ("invalid utf8 passed to VFormat. Limping
along.");
- *end =3D '\0';
+ // *end =3D '\0';
+ *end =3D ' ';
}
buf =3D _fold_lines (buf);
TRACE 1:=20
[1136900506.519306] =
Input vcal is:
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
ATTENDEE;CN=3DR=C3=A9my Amouroux;ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE;
PARTSTAT=3DACCEPTED:MAILTO:rem...@ke...
ORGANIZER:MAILTO:va...@am...
DTSTART:20050922T060000Z
DTEND:20050922T080000Z
TRANSP:OPAQUE
SEQUENCE:0
UID:
040000008200E00074C5B7101A82E0080000000010E4575FC9AFC5010000000000000000=
10
000000B6F0CDF8F87227418E1C2A0DBE2BD607
DTSTAMP:20050902T121947Z
DESCRIPTION:Quand : jeudi 22 septembre 2005 08:00-10:00 (GMT+01:00)
Bruxelles\, Copenhague\, Madrid\, Paris.\n\n*~*~*~*~*~*~*~*~*~*\n\nTMV S=
t
Egreve 04/76/75/21/34\n\n\n\n
SUMMARY:Depannage Volet Budendorf
PRIORITY:5
CLASS:PUBLIC
X-MICROSOFT-CDO-REPLYTIME:20050902T135144Z
CREATED:20050902T135144
LAST-MODIFIED:20050902T135144
END:VEVENT
END:VCALENDAR
[1136900506.519512] =
Creating xml doc
[1136900506.519561] =
parsing attributes
[1136900506.519606] =
>>>>>>> vcal_parse_attributes(0xb6be6108, 0xc1f7818)
[1136900506.519652] =
>>>>>>> vcal_handle_attribute(0xc1f0548, 0xc1f7818, 0xc1f=
8320:PRODID)
[1136900506.519698] =
Hook is: 0x1
[1136900506.519741] =
<<<<<<< vcal_handle_attribute: Ignored
[1136900506.519787] =
>>>>>>> vcal_handle_attribute(0xc1f0548, 0xc1f7818, 0xc1f=
1678:VERSION)
[1136900506.519832] =
Hook is: 0x1
[1136900506.519876] =
<<<<<<< vcal_handle_attribute: Ignored
[1136900506.519920] =
>>>>>>> vcal_handle_attribute(0xc1f0548, 0xc1f7818, 0xc1f=
6cf8:METHOD)
[1136900506.519965] =
Hook is: 0x390c3c
[1136900506.520009] =
Handling method attribute
[1136900506.520058] =
<<<<<<< vcal_handle_attribute
[1136900506.520107] =
>>>>>>> vcal_parse_attributes(0xb6be60c8, 0xc1f7d40)
[1136900506.520152] =
<<<<<<< vcal_parse_attributes: Done
[1136900506.520195] =
<<<<<<< vcal_parse_attributes: Done
[1136900506.520281] =
Output XML is:
<?xml version=3D"1.0"?>
<vcal>
<Method>
<Content>PUBLISH</Content>
</Method>
<Event/>
</vcal>
TRACE 2:
[1136969487.644659] =
Output XML is:
<?xml version=3D"1.0"?>
<vcal>
<Method>
<Content>PUBLISH</Content>
</Method>
<Event>
<Attendee>
<Content>MAILTO:rem...@ke...</Content>
<CommonName>R my Amouroux</CommonName>
<Role>REQ-PARTICIPANT</Role>
<RSVP>TRUE</RSVP>
<PartStat>ACCEPTED</PartStat>
</Attendee>
<DateStarted>
<Content>20050922T060000Z</Content>
</DateStarted>
<DateEnd>
<Content>20050922T080000Z</Content>
</DateEnd>
<Transparency>
<Content>OPAQUE</Content>
</Transparency>
<Sequence>
<Content>0</Content>
</Sequence>
<DateCalendarCreated>
<Content>20050902T121947Z</Content>
</DateCalendarCreated>
<Description>
<Content>Quand : jeudi 22 septembre 2005 08:00-10:00 (GMT+01:00) Br=
uxelles, Copenhague, Madrid, Paris.
*~*~*~*~*~*~*~*~*~*
TMV St Egreve 04/76/75/21/34
</Content>
</Description>
<Summary>
<Content>Depannage Volet Budendorf</Content>
</Summary>
<Priority>
<Content>5</Content>
</Priority>
<Class>
<Content>PUBLIC</Content>
</Class>
<UnknownNode>
<NodeName>X-MICROSOFT-CDO-REPLYTIME</NodeName>
<Content>20050902T135144Z</Content>
</UnknownNode>
<DateCreated>
<Content>20050902T135144</Content>
</DateCreated>
<LastModified>
<Content>20050902T135144</Content>
</LastModified>
</Event>
</vcal>
[1136969487.644709] <=
<<<<<< conv_vcal_to_xml: TRUE
Le lundi 09 janvier 2006 =C3=A0 19:35 +0100, R=C3=A9my Amouroux a =C3=A9c=
rit :=20
> Hello
>=20
> I had a SIGSEV during my first sync between evo2 and the file-sync
> plugin.
>=20
> My investigation sofar shows that it is related to the presence of
> non-utf8 characters in the stuff sent by evo2.
--=20
E-mail : Re...@Am...
Web : http://www.amouroux.org/
Yahoo Id: kelkooremya
|
|
From: A. <rem...@ya...> - 2006-01-11 12:59:00
|
Hi all
I have no more SIGSEV after solving my problems with invalid utf8
events, but I found that I have now SIGABRT coming after some times.
I was able to pinpoint the problem to the fact that
osync_member_commit_change received NULL as value of its change
parameter.
It's clearly visible in TRACE 1.
>From a debug session, it seems that the message is coming from the
file_sync plugin with a NULL payload.
Since the problem was related to a message, I tried to follow that
message in the log files.
I found out that message 0xb310ebe0 had a problem (see trace 2)
The message is printed when the function timeoutfunc is called (file
osengine_queue.c).
In the same function, there is a call to itm_message_move_data, that is
reseting the payload of the message in timeout while moving it data to
the error message.
After that call, timeoutfunc is setting the message status to ANSWERED
thus, I believe, allowing the handler to deal with that message, and
then aborting because of the NULL payload.
Since I don't want to broke something in the engine and the queue
management, I need advice before trying to propose a modification.
Armin ?
Regards
RemyA
PS: I just saw the news about the conf. Good trip guys, and make us a
shining new release :-)
TRACE 1:
[1136979753.739199] >>>>>>> client_message_handler(0x8839810, 0xb310ebe0, 0x8833808)
[1136979753.739270] [CLI] DEBUG: Client message handler called for message "COMMIT_CHANGE"
[1136979753.739428] >>>>>>> osync_member_commit_change(0x8832320, (nil), 0xc16c14, 0xb310ebe0)
TRACE 2
[1136979753.733361] [ENG] ERROR: Timeout while waiting for a reply to message 0xb310ebe0:"COMMIT_CHANGE". Sending error 0xb32f8c70
--
E-mail : Rem...@ya...
Yahoo Architecture Europe (http://www.yahoo.com/)
Yahoo Id: kelkooremya
|
|
From: Armin B. <arm...@de...> - 2006-01-12 00:47:38
Attachments:
signature.asc
|
R=C3=A9my Amouroux wrote:
> Hello
>=20
> I had a SIGSEV during my first sync between evo2 and the file-sync
> plugin.
>=20
> My investigation sofar shows that it is related to the presence of
> non-utf8 characters in the stuff sent by evo2.
>=20
> in a first case, I was able to pinpoint the problem on the description
> and I just removed the description of the event (see trace 1). It seems=
> that by updating the event, I changed something and it was better.
>=20
> I had another problem, similar. see trace 2.
>=20
> Looks like my problems are related to old entries, so I will purge evo2=
> to make sure I don't have the problem anymore. But it would be cool to
> ensure that a SIGSEV cannot arise.
>=20
> thus ...
>=20
> I did a gdb session to understand where exactly was the SIGSEV. see
> trace 3.
>=20
> It seems that when vformat is creating a list of attributes that is not=
> valid, the function vcal_parse_attributes is not handling them well.
>=20
> Using a for loop is maybe not a good idea in that function since there
> are other location where the variable a is modified.
>=20
Hi,
thanks for your help!
i can confirm the crash. I added a test case for the vcal parser that
triggers the crash. The problem is that the vformat parser stops parsing
at the invalid utf8 input and therefore the resulting object is
different than what opensync expects.
so there are 3 issues to fix here:
- the crash. opensync should never ever crash.
- i guess its better if we return an error of the vformat parser cannot
parse the input than trying to return an invalid parsed object...
- add support for encodings besides utf8. this is a big item on my todo
list. internally opensync handles everything as utf8. but then we need a
parameter which specifies which encoding the input/output is.
Armin
> Regards
>=20
> remyA
>=20
> PS: trying to provide a diff later this night.
>=20
> trace 1:
> --------
> [1136825381.689302]
> Input vcal is:
> BEGIN:VCALENDAR
> PRODID:-//Ximian//NONSGML Evolution Calendar//EN
> VERSION:2.0
> METHOD:PUBLISH
> BEGIN:VEVENT
> ATTENDEE;CN=3DR=C3=A9my Amouroux;ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE;
> PARTSTAT=3DACCEPTED:MAILTO:re...@am...
> ORGANIZER:MAILTO:va...@am...
> DTSTART:20050726T053000Z
> DTEND:20050726T053000Z
> TRANSP:OPAQUE
> SEQUENCE:0
> UID:
>=20
> 040000008200E00074C5B7101A82E0080000000070D7AE8F808CC501000000000000000=
010
> 0000008C05F5F3D72E3B4C9A3BC7FBF434B6CD
> DTSTAMP:20050719T144024Z
> DESCRIPTION:Quand : mardi 26 juillet 2005 07:30-07:30 (GMT+01:00)
> Bruxelles\, Copenhague\, Madrid\, Paris.\n\n*~*~*~*~*~*~*~*~*~*\n\nSi
> tu
> pouvais =C3=83=C2=AAtre l=C3=83 ce serait bien\n
> SUMMARY:ATEc verification de la toiture Mr Domenec
> PRIORITY:5
> CLASS:PUBLIC
> X-MICROSOFT-CDO-REPLYTIME:20050719T153821Z
> CREATED:20050719T153821
> LAST-MODIFIED:20050719T153821
> END:VEVENT
> END:VCALENDAR
>=20
> [1136825381.689552]
> Creating xml doc
> [1136825381.689615]
> parsing attributes
> [1136825381.689674]
>=20
>>>>>>>> vcal_parse_attributes(0xb6b51108, 0xac99ea8)
>=20
> [1136825381.689734]
>=20
>>>>>>>> vcal_handle_attribute(0xac94b80, 0xac99ea8, 0xac99cf0:PRODID)
>=20
> [1136825381.689793]
> Hook is: 0x1
> [1136825381.689851]
> <<<<<<< vcal_handle_attribute: Ignored
> [1136825381.689910]
>=20
>>>>>>>> vcal_handle_attribute(0xac94b80, 0xac99ea8, 0xac99f10:VERSION)
>=20
> [1136825381.689969]
> Hook is: 0x1
> [1136825381.690027]
> <<<<<<< vcal_handle_attribute: Ignored
> [1136825381.690086]
>=20
>>>>>>>> vcal_handle_attribute(0xac94b80, 0xac99ea8, 0xac9aaa8:METHOD)
>=20
> [1136825381.690144]
> Hook is: 0xdb9c3c
> [1136825381.690200]
> Handling method attribute
> [1136825381.690264]
> <<<<<<< vcal_handle_attribute
> [1136825381.690330]
>=20
>>>>>>>> vcal_parse_attributes(0xb6b510c8, 0xac9afb8)
>=20
> [1136825381.690389]
> <<<<<<< vcal_parse_attributes: Done
> (log file ended her)
>=20
> trace 2
> -------
> [1136826678.223093]
> Input vcal is:
> BEGIN:VCALENDAR
> PRODID:-//Ximian//NONSGML Evolution Calendar//EN
> VERSION:2.0
> METHOD:PUBLISH
> BEGIN:VEVENT
> ATTENDEE;CN=3DR=C3=A9my Amouroux;ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE;
> PARTSTAT=3DACCEPTED:MAILTO:rem...@ke...
> ORGANIZER:MAILTO:va...@am...
> DTSTART:20050922T060000Z
> DTEND:20050922T080000Z
> TRANSP:OPAQUE
> SEQUENCE:0
> UID:
>=20
> 040000008200E00074C5B7101A82E0080000000010E4575FC9AFC501000000000000000=
010
> 000000B6F0CDF8F87227418E1C2A0DBE2BD607
> DTSTAMP:20050902T121947Z
> DESCRIPTION:Quand : jeudi 22 septembre 2005 08:00-10:00 (GMT+01:00)
> Bruxelles\, Copenhague\, Madrid\, Paris.\n\n*~*~*~*~*~*~*~*~*~*\n\nTMV=
> St
> Egreve 04/76/75/21/34\n\n\n\n
> SUMMARY:Depannage Volet Budendorf
> PRIORITY:5
> CLASS:PUBLIC
> X-MICROSOFT-CDO-REPLYTIME:20050902T135144Z
> CREATED:20050902T135144
> LAST-MODIFIED:20050902T135144
> END:VEVENT
> END:VCALENDAR
>=20
> [1136826678.223346]
> Creating xml doc
> [1136826678.223411]
> parsing attributes
> [1136826678.223469]
>=20
>>>>>>>> vcal_parse_attributes(0xb6b36108, 0xb1d915b8)
>=20
> [1136826678.223529]
>=20
>>>>>>>> vcal_handle_attribute(0xb1d8afb8, 0xb1d915b8,
>=20
> 0xb1d92110:PRODID)
> [1136826678.223632]
> Hook is: 0x1
> [1136826678.223691]
> <<<<<<< vcal_handle_attribute: Ignored
> [1136826678.223750]
>=20
>>>>>>>> vcal_handle_attribute(0xb1d8afb8, 0xb1d915b8,
>=20
> 0xb1d92130:VERSION)
> [1136826678.223811]
> Hook is: 0x1
> [1136826678.223868]
> <<<<<<< vcal_handle_attribute: Ignored
> [1136826678.223927]
>=20
>>>>>>>> vcal_handle_attribute(0xb1d8afb8, 0xb1d915b8,
>=20
> 0xb1d91540:METHOD)
> [1136826678.223989]
> Hook is: 0xe3dc3c
> [1136826678.224046]
> Handling method attribute
> [1136826678.224111]
> <<<<<<< vcal_handle_attribute
> [1136826678.224176]
>=20
>>>>>>>> vcal_parse_attributes(0xb6b360c8, 0xb1d92510)
>=20
> [1136826678.224233]
> <<<<<<< vcal_parse_attributes: Done
>=20
>=20
> trace3:
> ------
> Received a entry 20050525T023411Z-5011-100-1-5@remya with data of size =
4
> from member 1. Changetype ADDED
>=20
> ** (process:12799): WARNING **: invalid utf8 passed to VFormat. Limpin=
g
> along.
>=20
> ** (process:12799): WARNING **: vcard ended without END:VCARD
>=20
>=20
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1229993040 (LWP 12804)]
> 0x003fcf3e in vcal_parse_attributes (hooks=3D0xb1624d58, table=3D0xb162=
4ab0,
> paramtable=3D0xb1624ab0, attributes=3D0xb6afc108, root=3D0xb162c240)
> at xml-vcal.c:676
> 676 for (a =3D *attributes; a; a =3D a->next) {
> (gdb) print a
> $1 =3D (GList *) 0x0
> (gdb) print attributes
> $2 =3D (GList **) 0xb6afc108
> (gdb) print *attributes
> $3 =3D (GList *) 0xb16233f8
> (gdb) print *attributes-next
> No symbol "next" in current context.
> (gdb) print *attributes->next
> $4 =3D {data =3D 0xb162b498, next =3D 0xb1623428, prev =3D 0xb16233f8}
> (gdb) print *attributes->next->next
> $5 =3D {data =3D 0xb162bfa8, next =3D 0xb1623440, prev =3D 0xb1623410}
> (gdb) print **attr
> Structure has no component named operator*.
> (gdb) print *attr
> $6 =3D {group =3D 0x0, name =3D 0xb16280b8 "BEGIN", params =3D 0x0, val=
ues =3D
> 0xb1623434, decoded_values =3D 0xb1623458, encoding =3D VF_ENCODING_RAW=
,
> encoding_set =3D 0}
> (gdb) print *attr->values
> $7 =3D {data =3D 0xb162b618, next =3D 0x0, prev =3D 0x0}
> (gdb) print *attr->values->data
> Attempt to dereference a generic pointer.
> (gdb)
>=20
|
|
From: A. <rem...@ya...> - 2006-01-12 13:26:46
|
Le jeudi 12 janvier 2006 =C3=A0 01:48 +0100, Armin Bauer a =C3=A9crit : > thanks for your help! you are welcome > i can confirm the crash. I added a test case for the vcal parser that > triggers the crash. The problem is that the vformat parser stops parsin= g > at the invalid utf8 input and therefore the resulting object is > different than what opensync expects. i should take a look at the test creation, it will help me provide diff proposals faster :-) >=20 > so there are 3 issues to fix here: >=20 > - the crash. opensync should never ever crash. I think the diff I provide in another message answers to that point. >=20 > - i guess its better if we return an error of the vformat parser cannot > parse the input than trying to return an invalid parsed object... it depends what you think your users want and what are the responsibilities of the plugins. if the plugins is not required to provide valid utf8, I think we have to deal with that problem in opensync. It's what I did in the second diff I provide in that other message. if the plugin is required to provide utf8 (and I think it is valid to require that from a plugin developper), the parser should return an error if the input is not valid. > - add support for encodings besides utf8. this is a big item on my todo > list. internally opensync handles everything as utf8. but then we need = a > parameter which specifies which encoding the input/output is. support to help plugin developper dealing with the utf8 transformation, yes, I agree. I think it would be an error to put too many things in the engine itself. For me, there is a clear separation in term of roles between plugin and engine. 1) the engine ensures communication between plugins and provides the common format used to communicate 2) the plugin is in charge of the access to the terminal (evo2, phone, etc) and it is in charge of the necessary transformation of the data between terminal and engine. So, which part should be in charge of the charset translation ? :-) RemyA --=20 E-mail : Rem...@ya... Yahoo Architecture Europe (http://www.yahoo.com/) Yahoo Id: kelkooremya |
|
From: Armin B. <arm...@de...> - 2006-01-15 23:33:05
Attachments:
signature.asc
|
R=C3=A9my Amouroux wrote: > Le jeudi 12 janvier 2006 =C3=A0 01:48 +0100, Armin Bauer a =C3=A9crit := >=20 >>thanks for your help! >=20 >=20 > you are welcome >=20 >=20 >>i can confirm the crash. I added a test case for the vcal parser that >>triggers the crash. The problem is that the vformat parser stops parsin= g >>at the invalid utf8 input and therefore the resulting object is >>different than what opensync expects. >=20 >=20 > i should take a look at the test creation, it will help me provide diff= > proposals faster :-) >=20 >=20 >>so there are 3 issues to fix here: >> >>- the crash. opensync should never ever crash. >=20 >=20 > I think the diff I provide in another message answers to that point. yes it definitely does. >=20 >=20 >>- i guess its better if we return an error of the vformat parser cannot= >>parse the input than trying to return an invalid parsed object... >=20 >=20 > it depends what you think your users want and what are the > responsibilities of the plugins. > if the plugins is not required to provide valid utf8, I think we have t= o > deal with that problem in opensync. > It's what I did in the second diff I provide in that other message. >=20 > if the plugin is required to provide utf8 (and I think it is valid to > require that from a plugin developper), the parser should return an > error if the input is not valid. internally i require all data to be utf8 so i we should just return an error if its not valid utf8. >=20 >=20 >>- add support for encodings besides utf8. this is a big item on my todo= >>list. internally opensync handles everything as utf8. but then we need = a >>parameter which specifies which encoding the input/output is. >=20 >=20 > support to help plugin developper dealing with the utf8 transformation,= > yes, I agree. >=20 > I think it would be an error to put too many things in the engine > itself. >=20 > For me, there is a clear separation in term of roles between plugin and= > engine. >=20 > 1) the engine ensures communication between plugins and provides the > common format used to communicate > 2) the plugin is in charge of the access to the terminal (evo2, phone, > etc) and it is in charge of the necessary transformation of the data > between terminal and engine. >=20 > So, which part should be in charge of the charset translation ? my idea for this would be to add 2 parameters to the conversion routines: charset of the incoming change, and the requested charset of the converted change. so the engine would request all conversions to be to utf8. On the conversion back, the plugin requests the charset it wants (probably depending on device settings etc). >=20 > :-) >=20 > RemyA >=20 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X