Bug 825244

Created attachment 586938 [details]
Difference between stap -p3 output befor/after the tweak

We found a workaround that seems to work for bug #804632.

If we tweak the script as follows it seems to not trigger the error:

@@ -320,7 +320,7 @@
               if (used != 1)
                 {
                   // Something very odd has happened.
-                  frame = sprintf("<unused_code_block@0x%x>", pc);
+                  frame = "<unused_code_block>";
                   blob_name = "unused";
                   trust_fp = 0;
                   frame_size = 0;
@@ -444,7 +444,7 @@
             {
               // Some assumption above totally failed and we got an address
               // read error. Give up and mark frame pointer as suspect.
-              frame = sprintf("<unknown_frame@0x%x>", pc);
+              frame = "<unknown_frame>";
               trust_fp = 0;
             }
         }

Attached is the diff between the stap -p3 -e 'probe hotspot.jni.GetStringUTFChars { print_jstack_full() }' output.

The relevant hunks of the diff seem to be:

@@ -3940,21 +3866,8 @@
                   {
                     (void) 
                     ({
-                      strlcpy (l->__tmp75, 
-                      ({
-                        l->__tmp77 = l->pc;
-                        #ifndef STP_LEGACY_PRINT
-                          c->printf_locals.stp_sprintf_1.arg0 = l->__tmp77;
-                          c->printf_locals.stp_sprintf_1.__retvalue = l->__tmp78;
-                          stp_sprintf_1 (c);
-                        #else // STP_LEGACY_PRINT
-                          _stp_snprintf (l->__tmp78, MAXSTRINGLEN, "<unused_code_block@0x%llx>", l->__tmp77);
-                        #endif // STP_LEGACY_PRINT
-                        if (unlikely(c->last_error)) goto out;
-                        l->__tmp78;
-                      }), MAXSTRINGLEN);
-                      strlcpy (l->frame, l->__tmp75, MAXSTRINGLEN);
-                      l->__tmp75;
+                      strlcpy (l->frame, "<unused_code_block>", MAXSTRINGLEN);
+                      "<unused_code_block>";
                     });
                     
                     (void) 

@@ -4575,21 +4488,8 @@
             {
               (void) 
               ({
-                strlcpy (l->__tmp189, 
-                ({
-                  l->__tmp191 = l->pc;
-                  #ifndef STP_LEGACY_PRINT
-                    c->printf_locals.stp_sprintf_4.arg0 = l->__tmp191;
-                    c->printf_locals.stp_sprintf_4.__retvalue = l->__tmp192;
-                    stp_sprintf_4 (c);
-                  #else // STP_LEGACY_PRINT
-                    _stp_snprintf (l->__tmp192, MAXSTRINGLEN, "<unknown_frame@0x%llx>", l->__tmp191);
-                  #endif // STP_LEGACY_PRINT
-                  if (unlikely(c->last_error)) goto out;
-                  l->__tmp192;
-                }), MAXSTRINGLEN);
-                strlcpy (l->frame, l->__tmp189, MAXSTRINGLEN);
-                l->__tmp189;
+                strlcpy (l->frame, "<unknown_frame>", MAXSTRINGLEN);
+                "<unknown_frame>";
               });
               
               (void) 

What surprises me is that -DSTP_LEGACY_PRINT doesn't seem to make a difference in this case.

So it might be the two calls to strlcpy() which are to an exported symbol of the kernel and so cannot be inlined/optimized. Maybe we should have a static _stp_strlcpy() instead? Or would the optimizations/inlining lead to possible more stack usage?

This seems RHEL specific. The issue doesn't occur on Fedora 17. The following update is needed to the openjdk package on F17: https://admin.fedoraproject.org/updates/FEDORA-2012-8424/java-1.7.0-openjdk-1.7.0.3-2.1.fc17.7

Note Fedora 17 has different versions of everything of course, newer gcc (4.7 instead of 4.4) and openjdk (1.7 instead of 1.6). So they might not be comparible at all.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

As per bug #1008567, upstream patch is available to bump up
the 256 safety limit to 512.

Closing as DUP due to raising the warning threshold, but the code generation differences might merit further study.

*** This bug has been marked as a duplicate of bug 1008567 ***