I'm not sure if it's the same issue as you are having, but we have experienced crashes related to headers as well with the following stacktrace:
Thread 7 Crashed:
0 App 0x00073900 pjsip_contact_hdr_print + 180
1 App 0x00073d64 pjsip_msg_print + 380
2 App 0x0007f298 pjsip_tx_data_encode + 164
3 App 0x0007de98 stateless_send_resolver_callback + 180
4 App 0x0007ee18 srv_resolver_cb + 76
5 App 0x00031a58 dns_callback + 652
6 App 0x0002e114 on_read_complete + 1004
7 App 0x0001ffc4 ioqueue_dispatch_read_event + 396
8 App 0x000211e0 pj_ioqueue_poll + 688
9 App 0x0007b5f8 pjsip_endpt_handle_events2 + 196
10 App 0x00097158 pjsua_handle_events + 60
11 App 0x0009721c worker_thread + 20
12 App 0x000220c4 thread_main + 76
13 libSystem.B.dylib 0x0007a285 _pthread_start + 249
Is you stacktrace looking something similiar?
Best regards,
Even Andr?
On 16. des. 2010, at 11.13, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20101216/d4fb3725/attachment-0001.html>
