No, that doesn't fix it. What does, without being too much of a hack, is
dynamically allocating the memory for tmp_hdr, instead of putting it on
the stack.
pjsip_generic_array_hdr *tmp_hdr =
malloc(sizeof(pjsip_generic_array_hdr));
/* Init temporary header */
pjsip_generic_array_hdr_init(dlg->pool, tmp_hdr, NULL);
pj_memcpy(tmp_hdr, hdr, sizeof(pjsip_hdr));
while (hdr) {
unsigned j;
/* Append the header content to temporary header */
for(j=0; j<hdr->count &&
tmp_hdr->count<PJSIP_GENERIC_ARRAY_MAX_COUNT; ++j)
{
tmp_hdr->values[tmp_hdr->count++] =
hdr->values[j];
}
/* Get the next header for this capability */
hdr = (const pjsip_generic_array_hdr*)
pjsip_msg_find_hdr(msg, htypes[i], hdr->next);
}
/* Save this capability */
status = pjsip_dlg_set_remote_cap_hdr(dlg, tmp_hdr);
free(tmp_hdr);
if (status != PJ_SUCCESS) {
pjsip_dlg_dec_lock(dlg);
return status;
}
Still, seems unnecessary, because that tmp_hdr on the stack looks pretty
ok to me, from an application programmers point of view. Maybe one should
ask the GCC folks, what they think about it?
I would still be interested, if that is related to the Apple GCC version,
or if someone who is building PJSIP on Linux/Unix is able to reproduce
this issue?
Sebastian.
pjsip-bounces at lists.pjsip.org schrieb am 17.12.2010 08:19:07:
| Von: Benny Prijono <bennylp at teluu.com>
| An: pjsip list <pjsip at lists.pjsip.org>
| Datum: 17.12.2010 08:19
| Betreff: Re: [pjsip] crash with gcc and -Os on iOS
| Gesendet von: pjsip-bounces at lists.pjsip.org
|
| That's strange indeed. But we've had problem with certain gcc
| optimizations before, https://trac.pjsip.org/repos/ticket/23, and just
| as this one we also don't know what's going on.
|
| Can you avoid the problem using a lighter expression than printf? Say,
| with PJ_UNUSED_ARG(tmp_hdr.name.ptr).
|
| Best regards,
| Benny
|
|
| On Thu, Dec 16, 2010 at 5:13 PM, <s.marek at avm.de> wrote:
| > Hello,
| >
| > there's a strange issue with PJSIP 1.8.10 on iOS. XCodes default
| > optimization level for Release builds is -Os. When compiled this way,
| > PJSIPs header parser crashes on incoming calls.
| > When compiling with -O2 or even -O3, everything works fine. XCode uses
gcc
| > 4.2 underneath.
| >
| > I've narrowed it down to a loop that copies header-values into a
temporary
| > header-structure in pjsip_dlg_update_remote_cap().
| >
| > while (hdr) {
| > unsigned j;
| > /* Append the header content to temporary header */
| > for(j=0; j<hdr->count &&
| > tmp_hdr.count<PJSIP_GENERIC_ARRAY_MAX_COUNT; ++j)
| > {
| > tmp_hdr.values[tmp_hdr.count++] =
hdr->values[j];
| > }
| >
| > /* Get the next header for this capability */
| > hdr = (const pjsip_generic_array_hdr*)
| > pjsip_msg_find_hdr(msg, htypes[i], hdr->next);
| > }
| >
| > Looks good to me. But shortly after that, some pj_strdup (from
| > pjsip_hdr_clone) tries to copy those strings from tmp_hdr.values and
| > there's only garbage in tmp_hdr.values. tmp_hdr.count is fine though.
| >
| > When I modify the code by adding just a printf below(!!!) the
while-loop,
| > gcc's optimizer is brought back to sanity again and the values are
copied
| > just fine.
| >
| > while (hdr) {
| > unsigned j;
| > /* Append the header content to temporary header */
| > for(j=0; j<hdr->count &&
| > tmp_hdr.count<PJSIP_GENERIC_ARRAY_MAX_COUNT; ++j)
| > {
| > tmp_hdr.values[tmp_hdr.count++] =
hdr->values[j];
| > }
| >
| > /* Get the next header for this capability */
| > hdr = (const pjsip_generic_array_hdr*)
| > pjsip_msg_find_hdr(msg, htypes[i], hdr->next);
| > }
| > printf("[tmp_hdr] %s values (%d)\n", tmp_hdr.name.ptr,
| > tmp_hdr.count);
| >
| > An alterative "fix" was to add a printf on some tmp_hdr value inside
the
| > inner for loop. So in the end I think, gcc gets something wrong by
| > optimizing access to tmp_hdr too much.
| >
| > Does anyone know what the real source of the problem might be? What
has
| > Apple done to good old gcc? Or is this even reproducable on a
Unix/Linux
| > platform? Or is it just me?
| >
| > Thanks in advance for any comment,
| > Sebastian.
| >
| > _______________________________________________
| > Visit our blog: http://blog.pjsip.org
| >
| > pjsip mailing list
| > pjsip at lists.pjsip.org
| > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
| >
|
| _______________________________________________
| Visit our blog: http://blog.pjsip.org
|
| pjsip mailing list
| pjsip at lists.pjsip.org
| http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
