I have build application based on boost::asio. Sometimes I got this kind of core dump (not regullary). I tried investigate what's going on but I haven't more ideas to solve it.
In my point of view I think that could be some problem inside io service object - I mean maybe any bug? Should I update it ?
Anybody can explain what does memcpy() do in this case ? What is a reason of core ?
More details:
Platform . SunOS.
Boost - 1.49
/app/bin/executor_3'executor_dumpstack+0x13 [0x426645]
/app/bin/executor_3'signal_dumpstack+0x9d [0x426625]
/lib/amd64/libc.so.1'__sighndlr+0x6 [0xfffffd7fff224ea6]
/lib/amd64/libc.so.1'call_user_handler+0x2a4 [0xfffffd7fff217b5c]
/lib/amd64/libc.so.1'memcpy+0x1929 [0xfffffd7fff18a449] [Signal 11 (SEGV)]
/opt/lib/extralibs/exe_io.so'_ZNK5boost4_mfi3mf2Iv3GETRKNS_6system10error_codeEmE4callINS_10shared_ptrIS2_EES5_mEEvRT_PKvRT0_RT1_+0x8b [0xfffffd7ff64ff869]
/opt/lib/extralibs/exe_io.so'_ZNK5boost4_mfi3mf2Iv3GETRKNS_6system10error_codeEmEclINS_10shared_ptrIS2_EEEEvRT_S6_m+0x3c [0xfffffd7ff64fe47e]
/opt/lib/extralibs/exe_io.so'_ZN5boost3_bi5list3INS0_5valueINS_10shared_ptrI3GETEEEEPFNS_3argILi1EEEvEPFNS7_ILi2EEEvEEclINS_4_mfi3mf2IvS4_RKNS_6system10error_codeEmEENS0_5list2ISL_RKmEEEEvNS0_4typeIvEERT_RT0_i+0x72 [0xfffffd7ff64fce58]
/opt/lib/extralibs/exe_io.so'_ZN5boost3_bi6bind_tIvNS_4_mfi3mf2Iv3GETRKNS_6system10error_codeEmEENS0_5list3INS0_5valueINS_10shared_ptrIS4_EEEEPFNS_3argILi1EEEvEPFNSF_ILi2EEEvEEEEclIS6_mEEvRKT_RKT0_+0x43 [0xfffffd7ff64fbfa7]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio6detail17read_streambuf_opINS0_19basic_stream_socketINS0_2ip3tcpENS0_21stream_socket_serviceIS5_EEEESaIcENS1_18transfer_exactly_tENS_3_bi6bind_tIvNS_4_mfi3mf2Iv3GETRKNS_6system10error_codeEmEENSB_5list3INSB_5valueINS_10shared_ptrISF_EEEEPFNS_3argILi1EEEvEPFNSQ_ILi2EEEvEEEEEEclESJ_mi+0x16f [0xfffffd7ff64fa31b]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio6detail7binder2INS1_17read_streambuf_opINS0_19basic_stream_socketINS0_2ip3tcpENS0_21stream_socket_serviceIS6_EEEESaIcENS1_18transfer_exactly_tENS_3_bi6bind_tIvNS_4_mfi3mf2Iv3GETRKNS_6system10error_codeEmEENSC_5list3INSC_5valueINS_10shared_ptrISG_EEEEPFNS_3argILi1EEEvEPFNSR_ILi2EEEvEEEEEEESI_mEclEv+0x2d [0xfffffd7ff6503345]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio19asio_handler_invokeINS0_6detail7binder2INS2_17read_streambuf_opINS0_19basic_stream_socketINS0_2ip3tcpENS0_21stream_socket_serviceIS7_EEEESaIcENS2_18transfer_exactly_tENS_3_bi6bind_tIvNS_4_mfi3mf2Iv3GETRKNS_6system10error_codeEmEENSD_5list3INSD_5valueINS_10shared_ptrISH_EEEEPFNS_3argILi1EEEvEPFNSS_ILi2EEEvEEEEEEESJ_mEEEEvT_z+0x8e [0xfffffd7ff6502d76]
/opt/lib/extralibs/exe_io.so'_ZN33boost_asio_handler_invoke_helpers6invokeIN5boost4asio6detail7binder2INS3_17read_streambuf_opINS2_19basic_stream_socketINS2_2ip3tcpENS2_21stream_socket_serviceIS8_EEEESaIcENS3_18transfer_exactly_tENS1_3_bi6bind_tIvNS1_4_mfi3mf2Iv3GETRKNS1_6system10error_codeEmEENSE_5list3INSE_5valueINS1_10shared_ptrISI_EEEEPFNS1_3argILi1EEEvEPFNST_ILi2EEEvEEEEEEESK_mEES11_EEvRT_RT0_+0x3e [0xfffffd7ff650250a]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio6detail19asio_handler_invokeINS1_7binder2INS1_17read_streambuf_opINS0_19basic_stream_socketINS0_2ip3tcpENS0_21stream_socket_serviceIS7_EEEESaIcENS1_18transfer_exactly_tENS_3_bi6bind_tIvNS_4_mfi3mf2Iv3GETRKNS_6system10error_codeEmEENSD_5list3INSD_5valueINS_10shared_ptrISH_EEEEPFNS_3argILi1EEEvEPFNSS_ILi2EEEvEEEEEEESJ_mEESA_SB_SC_S10_EEvRT_PNS4_IT0_T1_T2_T3_EE+0x21 [0xfffffd7ff6501f61]
/opt/lib/extralibs/exe_io.so'_ZN33boost_asio_handler_invoke_helpers6invokeIN5boost4asio6detail7binder2INS3_17read_streambuf_opINS2_19basic_stream_socketINS2_2ip3tcpENS2_21stream_socket_serviceIS8_EEEESaIcENS3_18transfer_exactly_tENS1_3_bi6bind_tIvNS1_4_mfi3mf2Iv3GETRKNS1_6system10error_codeEmEENSE_5list3INSE_5valueINS1_10shared_ptrISI_EEEEPFNS1_3argILi1EEEvEPFNST_ILi2EEEvEEEEEEESK_mEES12_EEvRT_RT0_+0x25 [0xfffffd7ff65019a3]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio6detail23reactive_socket_recv_opINS0_17mutable_buffers_1ENS1_17read_streambuf_opINS0_19basic_stream_socketINS0_2ip3tcpENS0_21stream_socket_serviceIS7_EEEESaIcENS1_18transfer_exactly_tENS_3_bi6bind_tIvNS_4_mfi3mf2Iv3GETRKNS_6system10error_codeEmEENSD_5list3INSD_5valueINS_10shared_ptrISH_EEEEPFNS_3argILi1EEEvEPFNSS_ILi2EEEvEEEEEEEE11do_completeEPNS1_15task_io_serviceEPNS1_25task_io_service_operationESL_m+0xc4 [0xfffffd7ff65007cc]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio6detail25task_io_service_operation8completeERNS1_15task_io_serviceERKNS_6system10error_codeEm+0x32 [0xfffffd7ff6433dc8]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio6detail15task_io_service10do_run_oneERNS1_11scoped_lockINS1_11posix_mutexEEERNS2_11thread_infoERNS1_8op_queueINS1_25task_io_service_operationEEERKNS_6system10error_codeE+0x202 [0xfffffd7ff6433c9e]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio6detail15task_io_service3runERNS_6system10error_codeE+0xff [0xfffffd7ff6433925]
/opt/lib/extralibs/exe_io.so'_ZN5boost4asio10io_service3runEv+0x26 [0xfffffd7ff64335d6]
/opt/lib/extralibs/exe_io.so'_ZN6ZohaIO9RunIOEv+0x19 [0xfffffd7ff64335ad]
/opt/lib/extralibs/exe_io.so'_ZNK5boost4_mfi3mf0Iv6ZohaIOEclEPS2_+0x64 [0xfffffd7ff6440cee]
/opt/lib/extralibs/exe_io.so'_ZN5boost3_bi5list1INS0_5valueIP6ZohaIOEEEclINS_4_mfi3mf0IvS3_EENS0_5list0EEEvNS0_4typeIvEERT_RT0_i+0x41 [0xfffffd7ff6440c4d]
/opt/lib/extralibs/exe_io.so'_ZN5boost3_bi6bind_tIvNS_4_mfi3mf0Iv6ZohaIOEENS0_5list1INS0_5valueIPS4_EEEEEclEv+0x33 [0xfffffd7ff6440bfb]
/opt/lib/extralibs/exe_io.so'_ZN5boost6detail11thread_dataINS_3_bi6bind_tIvNS_4_mfi3mf0Iv6ZohaIOEENS2_5list1INS2_5valueIPS6_EEEEEEE3runEv+0x1c [0xfffffd7ff6440514]
/opt/csw/gxx/lib/amd64/libboost_thread.so.1.49.0'0xf655 [0xfffffd7ffa97f655]
/lib/amd64/libc.so.1'_thrp_setup+0xbc [0xfffffd7fff224b14]
/lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7fff224de0]
objdump output.
0000000000000000 <_ZNK5boost4_mfi3mf2Iv3GETRKNS_6system10error_codeEmE4callINS_10shared_ptrIS2_EES5_mEEvRT_PKvRT0_RT1_>:
template<class U, class B1, class B2> R call(U & u, T const *, B1 & b1, B2 & b2) const
{
BOOST_MEM_FN_RETURN (u.*f_)(b1, b2);
}
template<class U, class B1, class B2> R call(U & u, void const *, B1 & b1, B2 & b2) const
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 53 push %rbx
5: 48 83 ec 38 sub $0x38,%rsp
9: 48 89 7d e8 mov %rdi,-0x18(%rbp)
d: 48 89 75 e0 mov %rsi,-0x20(%rbp)
11: 48 89 55 d8 mov %rdx,-0x28(%rbp)
15: 48 89 4d d0 mov %rcx,-0x30(%rbp)
19: 4c 89 45 c8 mov %r8,-0x38(%rbp)
{
BOOST_MEM_FN_RETURN (get_pointer(u)->*f_)(b1, b2);
1d: 48 8b 45 e0 mov -0x20(%rbp),%rax
21: 48 89 c7 mov %rax,%rdi
24: e8 00 00 00 00 callq 29 <_ZNK5boost4_mfi3mf2Iv3GETRKNS_6system10error_codeEmE4callINS_10shared_ptrIS2_EES5_mEEvRT_PKvRT0_RT1_+0x29>
29: 48 89 c2 mov %rax,%rdx
2c: 48 8b 45 e8 mov -0x18(%rbp),%rax
30: 48 8b 00 mov (%rax),%rax
33: 83 e0 01 and $0x1,%eax
36: 84 c0 test %al,%al
38: 74 23 je 5d <_ZNK5boost4_mfi3mf2Iv3GETRKNS_6system10error_codeEmE4callINS_10shared_ptrIS2_EES5_mEEvRT_PKvRT0_RT1_+0x5d>
3a: 48 8b 45 e8 mov -0x18(%rbp),%rax
3e: 48 8b 40 08 mov 0x8(%rax),%rax
42: 48 8d 04 02 lea (%rdx,%rax,1),%rax
46: 48 8b 08 mov (%rax),%rcx
49: 48 8b 45 e8 mov -0x18(%rbp),%rax
4d: 48 8b 00 mov (%rax),%rax
50: 48 83 e8 01 sub $0x1,%rax
54: 48 8d 04 01 lea (%rcx,%rax,1),%rax
58: 48 8b 00 mov (%rax),%rax
5b: eb 07 jmp 64 <_ZNK5boost4_mfi3mf2Iv3GETRKNS_6system10error_codeEmE4callINS_10shared_ptrIS2_EES5_mEEvRT_PKvRT0_RT1_+0x64>
5d: 48 8b 45 e8 mov -0x18(%rbp),%rax
61: 48 8b 00 mov (%rax),%rax
64: 48 8b 4d c8 mov -0x38(%rbp),%rcx
68: 48 8b 19 mov (%rcx),%rbx
6b: 48 8b 4d e8 mov -0x18(%rbp),%rcx
6f: 48 8b 49 08 mov 0x8(%rcx),%rcx
73: 48 8d 3c 0a lea (%rdx,%rcx,1),%rdi
77: 48 8b 4d d0 mov -0x30(%rbp),%rcx
7b: 48 89 da mov %rbx,%rdx
7e: 48 89 ce mov %rcx,%rsi
Hint: use c++filt utility so your backtrace will become readable: cat backtrace | c++filt
Something happen to async_read handler on GET invoking. Maybe this object is destroyed at the time handler is invoked, or some mess with parameters. Cant say accurately without code, but something with read callback is what can be seen from this backtrace.
Related
Consider this code:
int arr[4];
void foo(void)
{
arr[0] = arr[1];
}
compiled and objdumped as:
gcc t57.c -O3 -c && objdump -Dr t57.o
leading to:
0000000000000000 <foo>:
0: f3 0f 1e fa endbr64
4: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # a <foo+0xa>
6: R_X86_64_PC32 arr
a: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 10 <foo+0x10>
c: R_X86_64_PC32 arr-0x4
10: c3 retq
Here we see arr and arr-0x4.
Question: why not arr+0x4 and arr? Where this -0x4 comes from?
I have sample code to fetch regions from Google Cloud API. This sample code works fine from my laptop (windows with OpenJDK 1.8 version). But the same code fails from kubernetes environment which has suse linux with OpenJDK 1.8 version.
From Suse linux side I get :
Exception in thread "main" java.io.IOException: Error getting access token for service account: Remote host closed connection during handshake
at com.google.auth.oauth2.ServiceAccountCredentials.refreshAccessToken(ServiceAccountCredentials.java:444)
at com.google.auth.oauth2.OAuth2Credentials.refresh(OAuth2Credentials.java:157)
at com.google.auth.oauth2.OAuth2Credentials.getRequestMetadata(OAuth2Credentials.java:145)
at com.google.auth.oauth2.ServiceAccountCredentials.getRequestMetadata(ServiceAccountCredentials.java:603)
at com.google.auth.http.HttpCredentialsAdapter.initialize(HttpCredentialsAdapter.java:91)
at com.google.api.client.http.HttpRequestFactory.buildRequest(HttpRequestFactory.java:91)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.buildHttpRequest(AbstractGoogleClientRequest.java:404)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:514)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:455)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:565)
at sample.program.gcp.vpvn.regionList(vpvn.java:85)
at sample.program.gcp.vpvn.main(vpvn.java:307)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:994)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1340)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1315)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:264)
at com.google.api.client.http.javanet.NetHttpRequest.execute(NetHttpRequest.java:113)
at com.google.api.client.http.javanet.NetHttpRequest.execute(NetHttpRequest.java:84)
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1012)
at com.google.auth.oauth2.ServiceAccountCredentials.refreshAccessToken(ServiceAccountCredentials.java:441)
... 11 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:505)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
... 23 more
When I enable SSL debug, I am not getting much details to troubleshoot this issue:
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1616080171 bytes = { 119, 66, 219, 23, 171, 247, 221, 79, 45, 202, 181, 18, 229, 4, 65, 98, 207, 90, 0, 108, 43, 54, 80, 65, 39, 31, 49, 114 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
[write] MD5 and SHA1 hashes: len = 215
0000: 01 00 00 D3 03 03 60 53 6D 2B 77 42 DB 17 AB F7 ......`Sm+wB....
0010: DD 4F 2D CA B5 12 E5 04 41 62 CF 5A 00 6C 2B 36 .O-.....Ab.Z.l+6
0020: 50 41 27 1F 31 72 00 00 56 C0 24 C0 28 00 3D C0 PA'.1r..V.$.(.=.
0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5...
0040: 0F 00 39 00 38 C0 23 C0 27 00 3C C0 25 C0 29 00 ..9.8.#.'.<.%.).
0050: 67 00 40 C0 09 C0 13 00 2F C0 04 C0 0E 00 33 00 g.#...../.....3.
0060: 32 C0 2C C0 2B C0 30 00 9D C0 2E C0 32 00 9F 00 2.,.+.0.....2...
0070: A3 C0 2F 00 9C C0 2D C0 31 00 9E 00 A2 00 FF 01 ../...-.1.......
0080: 00 00 54 00 0A 00 08 00 06 00 17 00 18 00 19 00 ..T.............
0090: 0B 00 02 01 00 00 0D 00 1C 00 1A 06 03 06 01 05 ................
00A0: 03 05 01 04 03 04 01 04 02 03 03 03 01 03 02 02 ................
00B0: 03 02 01 02 02 00 17 00 00 00 00 00 1A 00 18 00 ................
00C0: 00 15 6F 61 75 74 68 32 2E 67 6F 6F 67 6C 65 61 ..oauth2.googlea
00D0: 70 69 73 2E 63 6F 6D pis.com
main, WRITE: TLSv1.2 Handshake, length = 215
[Raw write]: length = 220
0000: 16 03 03 00 D7 01 00 00 D3 03 03 60 53 6D 2B 77 ...........`Sm+w
0010: 42 DB 17 AB F7 DD 4F 2D CA B5 12 E5 04 41 62 CF B.....O-.....Ab.
0020: 5A 00 6C 2B 36 50 41 27 1F 31 72 00 00 56 C0 24 Z.l+6PA'.1r..V.$
0030: C0 28 00 3D C0 26 C0 2A 00 6B 00 6A C0 0A C0 14 .(.=.&.*.k.j....
0040: 00 35 C0 05 C0 0F 00 39 00 38 C0 23 C0 27 00 3C .5.....9.8.#.'.<
0050: C0 25 C0 29 00 67 00 40 C0 09 C0 13 00 2F C0 04 .%.).g.#...../..
0060: C0 0E 00 33 00 32 C0 2C C0 2B C0 30 00 9D C0 2E ...3.2.,.+.0....
0070: C0 32 00 9F 00 A3 C0 2F 00 9C C0 2D C0 31 00 9E .2...../...-.1..
0080: 00 A2 00 FF 01 00 00 54 00 0A 00 08 00 06 00 17 .......T........
0090: 00 18 00 19 00 0B 00 02 01 00 00 0D 00 1C 00 1A ................
00A0: 06 03 06 01 05 03 05 01 04 03 04 01 04 02 03 03 ................
00B0: 03 01 03 02 02 03 02 01 02 02 00 17 00 00 00 00 ................
00C0: 00 1A 00 18 00 00 15 6F 61 75 74 68 32 2E 67 6F .......oauth2.go
00D0: 6F 67 6C 65 61 70 69 73 2E 63 6F 6D ogleapis.com
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
main, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
Any hints on how to troubleshoot this issue?
Here with my sample code:
public static void main(String args[]) throws GeneralSecurityException, IOException {
Compute computeService = createComputeService();
Compute.Regions.List request = computeService.regions().list("imageagg-nonprod");
System.out.println("the list of regions for the selected project is \n");
RegionList response;
do {
response = request.execute();
if (response.getItems() == null) {
continue;
}
request.setPageToken(response.getNextPageToken());
} while (response.getNextPageToken() != null);
ArrayList regionNames = new ArrayList<String>();
HashMap<String, ArrayList<String>> ZoneList = new HashMap<>();
response.getItems().forEach(region -> {
ArrayList<String> zones = new ArrayList<String>();
regionNames.add(region.getName());
region.getZones().forEach(zone -> {
zones.add(Paths.get(URI.create(zone).getPath()).getFileName().toString());
});
ZoneList.put(region.getName(), zones);
});
System.out.println("list of region for selected project is \n");
regionNames.forEach(element -> {
System.out.println(element);
});
System.out.println("the names of regions and Zones for the selected Project is \n");
Set entries = ZoneList.entrySet();
Iterator it = entries.iterator();
while (it.hasNext()) {
Map.Entry pair = (Map.Entry) it.next();
System.out.println(pair.getKey() + " = " + pair.getValue());
}
machineList(ZoneList);
}
public static Compute createComputeService() throws IOException, GeneralSecurityException {
HttpTransport httpTransport = GoogleNetHttpTransport.newTrustedTransport();
String proxyHostOpt = "web-proxy.in.software.net";
int proxyPort = 8080;
JsonFactory jsonFactory = JacksonFactory.getDefaultInstance();
HttpTransport abc = new NetHttpTransport.Builder().trustCertificates(GoogleUtils.getCertificateTrustStore())
.setProxy(new Proxy(Proxy.Type.HTTP, InetSocketAddress.createUnresolved(proxyHostOpt, proxyPort))).build();
//GoogleCredential credential = GoogleCredential.getApplicationDefault(abc,jsonFactory);
List<String> scopes = new ArrayList<>();
//scopes.add("https://www.googleapis.com/auth/cloud-platform");
String jsonToken = "{\n" + " \"type\": \"service_account\",\n" + " \"project_id\": \"imageagg-nonprod\",\n" + " \"private_key_id\": \"99c871d2855b4d9388cc7a3a670a5764deb8c5e9\",\n" + " \"private_key\": \"-----BEGIN PRIVATE KEY-----\\nMIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDh9k2JcCFrDZfm\\ng9DONfKe8xATwljEsW8FXMbPzU5JoXXsy1CYgkeW+eqXguQxFZM3HuI1W+mGBxgE\\n/K2P7XvJxylv7NajpgNmm4KGIh4hOpi+Sn3GVS31ftGM5A/CYKhRpr5uskr5PEin\\nDYxl0hUnfTodJCT+uxPxoCeN8aWuq5s+BapKKB8KVduUqmz3f8GL2Pc5wlm/YyOK\\nJYC781MAzLIFe8cLAVUJrVETqOtFTPCjy0yMGiUKxkyL20C11WFwfdD5ou0SD+6U\\nsT1YD/15KYh9GvV1E2XIPGzVtSHvU9h7FDRqOa+05QP3uDHegrAAib4PHA/A7KPD\\nBwkA6sW/AgMBAAECggEAHCPBtS9vIfdP5uecfcmvHMdVRbiquFgGZOsQYTmGmdnP\\nJz2MnGmBA9a8tc=\\n-----END PRIVATE KEY-----\\n\",\n" + " \"client_email\": \"315654350484-compute#developer.gserviceaccount.com\",\n" + " \"client_id\": \"112960668\",\n" + " \"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\",\n" + " \"token_uri\": \"https://oauth2.googleapis.com/token\",\n" + " \"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\",\n" + " \"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/315654350484-compute%40developer.gserviceaccount.com\"\n" + "}";
ObjectMapper objectMapper = new ObjectMapper();
Map<String, Object> map
= objectMapper.readValue(jsonToken, new TypeReference<Map<String,Object>>(){});
scopes.add(ComputeScopes.COMPUTE);
scopes.add(ComputeScopes.CLOUD_PLATFORM);
//scopes.add(ComputeScopes.DEVSTORAGE_FULL_CONTROL);
GoogleCredentials credentials = GoogleCredentials.fromStream(IOUtils.toInputStream(jsonToken, StandardCharsets.UTF_8)).createScoped(scopes);
ServiceAccountCredentials serviceAccountCredentials = ServiceAccountCredentials.fromStream(IOUtils.toInputStream(jsonToken, StandardCharsets.UTF_8));
HttpRequestInitializer requestInitializer = new HttpCredentialsAdapter(credentials);
// Making call with credentials1 created with json string and proxy set as per requirements
return new Compute.Builder(abc, jsonFactory, requestInitializer).setApplicationName("hcmx").build();
}
My java version details:
java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Environment where code is running:
[root#hcm-pool-centos76-3 ~]# uname -a
Linux hcm-pool-centos76-3 3.10.0-1062.9.1.el7.x86_64 #1 SMP Fri Dec 6 15:49:49 UTC 2
The crash occurs in mshtml when we print the contents of a WebBrowser(ActiveX Control), in MFC Applications.
1) The print dialog is not opening.
For printing from webbrowser, we call the below function
ExecWB(OLECMDID_PRINT, OLECMDEXECOPT_PROMPTUSER, NULL, NULL);
2) The crash starts from preview.js (CPrintDoc_RectComplete method) of ieframe.dll.
3) It is crashing in mshtml, "mshtml!Tree::CIE9DocumentLayout::HandleLayoutBuilderError+0xc6"
4) It is giving "Break instruction exception - code 80000003" .
Could you please let us know if there is any hotfix available for this callstack.
The call stack of the crashing thread is
00 000000ea2e697dc0 00007ffb483c4097 mshtml!Tree::CIE9DocumentLayout::HandleLayoutBuilderError+0xc6
01 000000ea2e697e00 00007ffb47cea9fc mshtml!CMarkupPageLayout::CalcPageLayoutSize+0xa09bcf
02 000000ea2e697f90 00007ffb489a6b86 mshtml!CMarkupPageLayout::CalcTopLayoutSizeWithDefault+0x1c
03 000000ea2e697fc0 00007ffb47b13a7f mshtml!CContainerLayout::CalcSizeVirtual+0x166
04 000000ea2e6980c0 00007ffb4806969e mshtml!CLayout::CalcSize+0x247
05 000000ea2e698270 00007ffb480694a8 mshtml!CFlowLayout::MeasureSite+0x42b
06 000000ea2e6983f0 00007ffb4806936f mshtml!CFlowLayout::GetSiteWidth+0x123
07 000000ea2e6984a0 00007ffb48069959 mshtml!CLSMeasurer::GetSiteWidth+0xaf
08 000000ea2e698520 00007ffb4806b97b mshtml!CLineServices::VerticalAlignOneObjectFast+0x443
09 000000ea2e6985f0 00007ffb4806ea8a mshtml!CLineServices::VerticalAlignObjectsFast+0x2da
0a 000000ea2e698730 00007ffb483648f0 mshtml!CLSMeasurer::Measure+0x3c6
0b 000000ea2e6987c0 00007ffb48273b4d mshtml!CLSMeasurer::MeasureLine+0x3c
0c 000000ea2e698810 00007ffb4806b01f mshtml!CRecalcLinePtr::MeasureLine+0x2a6
0d 000000ea2e698980 00007ffb4806e3ea mshtml!CDisplay::RecalcLinesWithMeasurer+0x2f2
0e 000000ea2e698ae0 00007ffb4806d555 mshtml!CDisplay::RecalcLines+0x6a
0f 000000ea2e698d20 00007ffb48057c51 mshtml!CDisplay::RecalcView+0x54
10 000000ea2e698d60 00007ffb4803af3d mshtml!CFlowLayout::CalcTextSize+0x303
11 000000ea2e698ed0 00007ffb4805a85d mshtml!CFlowLayout::CalcSizeCoreCompat+0x4a9
12 000000ea2e699440 00007ffb47b13a7f mshtml!CFlowLayout::CalcSizeVirtual+0x89
13 000000ea2e6994d0 00007ffb4806969e mshtml!CLayout::CalcSize+0x247
14 000000ea2e699680 00007ffb480694a8 mshtml!CFlowLayout::MeasureSite+0x42b
15 000000ea2e699800 00007ffb4806936f mshtml!CFlowLayout::GetSiteWidth+0x123
16 000000ea2e6998b0 00007ffb48071555 mshtml!CLSMeasurer::GetSiteWidth+0xaf
17 000000ea2e699930 00007ffb511539fe mshtml!CEmbeddedILSObj::Fmt+0x261
18 000000ea2e699a50 00007ffb51154acf msls31!ProcessOneRun+0x2f1
19 000000ea2e699ba0 00007ffb511544fb msls31!FetchAppendEscCore+0x11f
1a 000000ea2e699ca0 00007ffb511543bf msls31!FiniFormatGeneralCase+0x11b
1b 000000ea2e699d70 00007ffb51153bef msls31!CreateLineCore+0x837
1c 000000ea2e699f10 00007ffb4806e2e7 msls31!LsCreateLine+0x11f
1d 000000ea2e699fa0 00007ffb480727c9 mshtml!CLSMeasurer::LSDoCreateLine+0x1c3
1e 000000ea2e69a170 00007ffb4806ebf8 mshtml!CLSMeasurer::LSMeasure+0x79
1f 000000ea2e69a290 00007ffb483648f0 mshtml!CLSMeasurer::Measure+0x160
20 000000ea2e69a320 00007ffb48273b4d mshtml!CLSMeasurer::MeasureLine+0x3c
21 000000ea2e69a370 00007ffb4806b01f mshtml!CRecalcLinePtr::MeasureLine+0x2a6
22 000000ea2e69a4e0 00007ffb4806e3ea mshtml!CDisplay::RecalcLinesWithMeasurer+0x2f2
23 000000ea2e69a640 00007ffb4806d555 mshtml!CDisplay::RecalcLines+0x6a
24 000000ea2e69a880 00007ffb48057c51 mshtml!CDisplay::RecalcView+0x54
25 000000ea2e69a8c0 00007ffb4803af3d mshtml!CFlowLayout::CalcTextSize+0x303
26 000000ea2e69aa30 00007ffb4805a85d mshtml!CFlowLayout::CalcSizeCoreCompat+0x4a9
27 000000ea2e69afa0 00007ffb47b13a7f mshtml!CFlowLayout::CalcSizeVirtual+0x89
28 000000ea2e69b030 00007ffb4806969e mshtml!CLayout::CalcSize+0x247
29 000000ea2e69b1e0 00007ffb480694a8 mshtml!CFlowLayout::MeasureSite+0x42b
2a 000000ea2e69b360 00007ffb4806936f mshtml!CFlowLayout::GetSiteWidth+0x123
2b 000000ea2e69b410 00007ffb48069959 mshtml!CLSMeasurer::GetSiteWidth+0xaf
2c 000000ea2e69b490 00007ffb4806b97b mshtml!CLineServices::VerticalAlignOneObjectFast+0x443
2d 000000ea2e69b560 00007ffb4806ea8a mshtml!CLineServices::VerticalAlignObjectsFast+0x2da
2e 000000ea2e69b6a0 00007ffb483648f0 mshtml!CLSMeasurer::Measure+0x3c6
2f 000000ea2e69b730 00007ffb48273b4d mshtml!CLSMeasurer::MeasureLine+0x3c
30 000000ea2e69b780 00007ffb48078d35 mshtml!CRecalcLinePtr::MeasureLine+0x2a6
31 000000ea2e69b8f0 00007ffb48065115 mshtml!CDisplay::RecalcLines+0x51f
32 000000ea2e69c4a0 00007ffb4807ea6c mshtml!CDisplay::UpdateView+0x1cc
33 000000ea2e69c670 00007ffb48059fde mshtml!CFlowLayout::CommitChanges+0xcb
34 000000ea2e69c770 00007ffb4803af3d mshtml!CFlowLayout::CalcTextSize+0x51c
35 000000ea2e69c8e0 00007ffb4805a85d mshtml!CFlowLayout::CalcSizeCoreCompat+0x4a9
36 000000ea2e69ce50 00007ffb47b13a7f mshtml!CFlowLayout::CalcSizeVirtual+0x89
37 000000ea2e69cee0 00007ffb48059e0c mshtml!CLayout::CalcSize+0x247
38 000000ea2e69d090 00007ffb480547b7 mshtml!CFlowLayout::DoLayout+0x461
39 000000ea2e69d200 00007ffb4797eea9 mshtml!CView::ExecuteLayoutTasks+0xe3
3a 000000ea2e69d290 00007ffb4820e9da mshtml!CView::EnsureView+0x43f
3b 000000ea2e69d370 00007ffb48356a72 mshtml!CElement::EnsureRecalcNotify+0xa4
3c 000000ea2e69d3b0 00007ffb47d095ff mshtml!CElement::EnsureRecalcNotify+0x1e
3d 000000ea2e69d3f0 00007ffb47d04046 mshtml!CDisplayPointer::MoveToMarkupPointer+0xaf
3e 000000ea2e69d460 00007ffb47d0446a mshtml!CSelectionManager::CreateTrackerForContext+0x19e
3f 000000ea2e69d500 00007ffb47d0434b mshtml!CSelectionManager::SetEditContext+0xe6
40 000000ea2e69d580 00007ffb47d04e65 mshtml!CSelectionManager::SetEditContextFromElement+0x18b
41 000000ea2e69d670 00007ffb47d07764 mshtml!CSelectionManager::SetInitialEditContext+0x45
42 000000ea2e69d6b0 00007ffb47d086bc mshtml!CSelectionManager::Initialize+0x2a8
43 000000ea2e69d6e0 00007ffb47a45272 mshtml!CHTMLEditor::Initialize+0x15c
44 000000ea2e69d760 00007ffb47cefa20 mshtml!CDoc::GetHTMLEditor+0x11a
45 000000ea2e69d7a0 00007ffb47c43116 mshtml!CElement::InjectInternal+0x807
46 000000ea2e69d960 00007ffb47cc5b29 mshtml!CElement::InjectTextOrHTML+0x38d
47 000000ea2e69da40 00007ffb47d4fc7d mshtml!CElement::put_innerText+0x29
48 000000ea2e69da80 00007ffb47c48429 mshtml!GS_BSTR+0x12b
49 000000ea2e69daf0 00007ffb47cdfed0 mshtml!CBase::ContextInvokeEx+0x658
4a 000000ea2e69dc10 00007ffb4820d0bd mshtml!CElement::VersionedInvokeEx+0xb7
4b 000000ea2e69dcc0 00007ffb465fa1e4 mshtml!CBase::PrivateInvokeEx+0x179
4c 000000ea2e69dd40 00007ffb466df12e jscript9!HostDispatch::CallInvokeEx+0x1b6
4d 000000ea2e69de10 00007ffb466df05b jscript9!HostDispatch::PutValueByDispId+0xb6
4e 000000ea2e69ded0 00007ffb466df00f jscript9!HostDispatch::PutValue+0x37
4f 000000ea2e69df10 00007ffb46734757 jscript9!HostDispatch::SetPropertyCore+0x6a
50 000000ea2e69df40 00007ffb4656420c jscript9!Js::JavascriptOperators::OP_SetProperty+0x2f8
51 000000ea2e69dfd0 00007ffb465644a2 jscript9!Js::JavascriptOperators::PatchPutValueNoFastPath+0x80
52 000000ea2e69e050 00007ffb4650e240 jscript9!Js::InterpreterStackFrame::Process+0x5553
53 000000ea2e69e390 000000ea217d0ddb jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x386
54 000000ea2e69e680 00007ffb46509eb3 js!CPrintDoc_RectComplete [res://ieframe.dll/preview.js # 2660,1]
55 000000ea2e69e6b0 00007ffb4672ae52 jscript9!amd64_CallFunction+0x93
56 000000ea2e69e710 00007ffb4650e240 jscript9!Js::InterpreterStackFrame::Process+0x1071
57 000000ea2e69ea50 000000ea217d0dfb jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x386
58 000000ea2e69ec90 00007ffb46509eb3 js!OnRectCompleteNext [res://ieframe.dll/preview.js # 742,1]
59 000000ea2e69ecc0 00007ffb4672ae52 jscript9!amd64_CallFunction+0x93
5a 000000ea2e69ed30 00007ffb4650e240 jscript9!Js::InterpreterStackFrame::Process+0x1071
5b 000000ea2e69f070 000000ea217d0de3 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x386
5c 000000ea2e69f2e0 00007ffb46509eb3 js!anonymous [Unknown script code # 1,1]
5d 000000ea2e69f310 00007ffb46509af1 jscript9!amd64_CallFunction+0x93
5e 000000ea2e69f360 00007ffb46509cfe jscript9!Js::JavascriptFunction::CallFunction<1>+0x6d
5f 000000ea2e69f3a0 00007ffb46509dff jscript9!Js::JavascriptFunction::CallRootFunction+0x110
60 000000ea2e69f480 00007ffb46509d58 jscript9!ScriptSite::CallRootFunction+0x63
61 000000ea2e69f4e0 00007ffb46623c42 jscript9!ScriptSite::Execute+0x122
62 000000ea2e69f570 00007ffb46658594 jscript9!JavascriptDispatch::InvokeOnSelf+0x102
63 000000ea2e69f5f0 00007ffb466586ab jscript9!JavascriptDispatch::InvokeEx+0x1e4
64 000000ea2e69f700 00007ffb480d43a9 jscript9!JavascriptDispatch::Invoke+0x7b
65 000000ea2e69f750 00007ffb47c84e73 mshtml!CWindow::ExecuteCallbackScript+0x144
66 000000ea2e69f8d0 00007ffb4797e57e mshtml!CWindow::FireTimeOut+0x295
67 000000ea2e69f960 00007ffb486236a1 mshtml!CPaintBeat::ProcessTimers+0x327
68 000000ea2e69fa00 00007ffb47a45ee9 mshtml!CPaintBeat::OnWMTimer+0x61
69 000000ea2e69fa30 00007ffb4796e166 mshtml!FormsOnTimer+0x9f
6a 000000ea2e69fa80 00007ffb7ad324fd mshtml!GlobalWndProc+0x1c6
6b 000000ea2e69fb00 00007ffb7ad32357 user32!UserCallWinProcCheckWow+0x149
6c 000000ea2e69fbd0 00007ffb48667b84 user32!DispatchMessageWorker+0x1a7
6d 000000ea2e69fc50 00007ffb785513f2 mshtml!ModelessThreadProc+0x1c4
6e 000000ea2e69fce0 00007ffb7aec54f4 kernel32!BaseThreadInitThunk+0x22
6f 000000ea2e69fd10 0000000000000000 ntdll!RtlUserThreadStart+0x34
I have just tried to add __attribute__ ((weak)) to one of my interrupt handler definitions and I notice the vector jump is not implemented — the interrupt body appears in the compiled binary though.
Example, with "weak" interrupt:
ISR(TIMER1_COMPA_vect, __attribute__ ((weak)))
{
// some compiled code
...
}
Resulting assembly code — no jump:
00000000 <__vectors>:
0: 48 c0 rjmp .+144 ; 0x92 <__ctors_end>
4: 92 c0 rjmp .+292 ; 0x12a <__bad_interrupt>
8: 90 c0 rjmp .+288 ; 0x12a <__bad_interrupt>
c: 8e c0 rjmp .+284 ; 0x12a <__bad_interrupt>
10: 8c c0 rjmp .+280 ; 0x12a <__bad_interrupt>
14: 8a c0 rjmp .+276 ; 0x12a <__bad_interrupt>
18: 88 c0 rjmp .+272 ; 0x12a <__bad_interrupt>
1c: 86 c0 rjmp .+268 ; 0x12a <__bad_interrupt>
20: 84 c0 rjmp .+264 ; 0x12a <__bad_interrupt>
24: 82 c0 rjmp .+260 ; 0x12a <__bad_interrupt>
28: 80 c0 rjmp .+256 ; 0x12a <__bad_interrupt>
2c: 7e c0 rjmp .+252 ; 0x12a <__bad_interrupt>
30: 7c c0 rjmp .+248 ; 0x12a <__bad_interrupt>
34: 7a c0 rjmp .+244 ; 0x12a <__bad_interrupt>
38: 78 c0 rjmp .+240 ; 0x12a <__bad_interrupt>
3c: 76 c0 rjmp .+236 ; 0x12a <__bad_interrupt>
40: 74 c0 rjmp .+232 ; 0x12a <__bad_interrupt>
44: 72 c0 rjmp .+228 ; 0x12a <__bad_interrupt>
48: 70 c0 rjmp .+224 ; 0x12a <__bad_interrupt>
4c: 6e c0 rjmp .+220 ; 0x12a <__bad_interrupt>
50: 6c c0 rjmp .+216 ; 0x12a <__bad_interrupt>
54: 6a c0 rjmp .+212 ; 0x12a <__bad_interrupt>
58: 68 c0 rjmp .+208 ; 0x12a <__bad_interrupt>
5c: 66 c0 rjmp .+204 ; 0x12a <__bad_interrupt>
60: 64 c0 rjmp .+200 ; 0x12a <__bad_interrupt>
64: 62 c0 rjmp .+196 ; 0x12a <__bad_interrupt>
68: 60 c0 rjmp .+192 ; 0x12a <__bad_interrupt>
6c: 5e c0 rjmp .+188 ; 0x12a <__bad_interrupt>
Now without the weak attribute:
00000000 <__vectors>:
0: 48 c0 rjmp .+144 ; 0x92 <__ctors_end>
4: 92 c0 rjmp .+292 ; 0x12a <__bad_interrupt>
8: 90 c0 rjmp .+288 ; 0x12a <__bad_interrupt>
c: 8e c0 rjmp .+284 ; 0x12a <__bad_interrupt>
10: 8c c0 rjmp .+280 ; 0x12a <__bad_interrupt>
14: 8a c0 rjmp .+276 ; 0x12a <__bad_interrupt>
18: 88 c0 rjmp .+272 ; 0x12a <__bad_interrupt>
1c: 29 c0 rjmp .+82 ; 0x70 <__vector_7>
20: 84 c0 rjmp .+264 ; 0x12a <__bad_interrupt>
24: 82 c0 rjmp .+260 ; 0x12a <__bad_interrupt>
28: 80 c0 rjmp .+256 ; 0x12a <__bad_interrupt>
2c: 7e c0 rjmp .+252 ; 0x12a <__bad_interrupt>
...
Is this a bug in avr-gcc (I have tried versions 5.3.x and 7.1.0) or have I missed something?
avr-libc implements the ISR vector table using weak symbols so that your code can define the proper symbol as non-weak to override the default ISR handler __bad_interrupt (cf. crt1/gcrt1.S in the avr-libc source code).
So only a non-weak ISR symbol will override the weak default handler ISR symbol from avr-libc.
You might consider having your non-weak symbol ISR call a weak symbol function if you need that overridability and can afford to spend the additional cycles and stack space required for the call.
I am trying to write a small library for highly optimised x86-64 bit operation code and am fiddling with inline asm.
While testing this particular case has caught my attention:
unsigned long test = 0;
unsigned long bsr;
// bit test and set 39th bit
__asm__ ("btsq\t%1, %0 " : "+rm" (test) : "rJ" (39) );
// bit scan reverse (get most significant bit id)
__asm__ ("bsrq\t%1, %0" : "=r" (bsr) : "rm" (test) );
printf("test = %lu, bsr = %d\n", test, bsr);
compiles and runs fine in both gcc and icc, but when I inspect the assembly I get differences
gcc -S -fverbose-asm -std=gnu99 -O3
movq $0, -8(%rbp)
## InlineAsm Start
btsq $39, -8(%rbp)
## InlineAsm End
movq -8(%rbp), %rax
movq %rax, -16(%rbp)
## InlineAsm Start
bsrq -16(%rbp), %rdx
## InlineAsm End
movq -8(%rbp), %rsi
leaq L_.str(%rip), %rdi
xorb %al, %al
callq _printf
I am wondering why so complicated? I am writing high performance code in which the number of instructions is critical. I am especially wondering why gcc makes a copy of my variable test before passing it to the second inline asm?
Same code compiled with icc gives far better results:
xorl %esi, %esi # test = 0
movl $.L_2__STRING.0, %edi # has something to do with printf
orl $32832, (%rsp) # part of function initiation
xorl %eax, %eax # has something to do with printf
ldmxcsr (%rsp) # part of function initiation
btsq $39, %rsi #106.0
bsrq %rsi, %rdx #109.0
call printf #111.2
despite the fact that gcc decides to keep my variables on the stack rather then in registers, what I do not understand is why make a copy of test before passing it to the second asm?
If I put test in as an input/output variable in the second asm
__asm__ ("bsrq\t%1, %0" : "=r" (bsr) , "+rm" (test) );
then those lines disappear.
movq $0, -8(%rbp)
## InlineAsm Start
btsq $39, -8(%rbp)
## InlineAsm End
## InlineAsm Start
bsrq -8(%rbp), %rdx
## InlineAsm End
movq -8(%rbp), %rsi
leaq L_.str(%rip), %rdi
xorb %al, %al
callq _printf
Is this gcc screwed up optimisation or am I missing some vital compiler switches? I do have icc for my production system, but if I decide to distribute the source code at some point then it will have to be able to compile with gcc too.
compilers used:
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
icc Version 12.0.2
I've tried your example on Linux like this (making it "evil" by forcing a stack ref/loc for test through using &test in the printf:):#include <stdio.h>
int main(int argc, char **argv)
{
unsigned long test = 0;
unsigned long bsr;
// bit test and set 39th bit
asm ("btsq\t%1, %0 " : "+rm" (test) : "rJ" (39) );
// bit scan reverse (get most significant bit id)
asm ("bsrq\t%1, %0" : "=r" (bsr) : "rm" (test) );
printf("test = %lu, bsr = %d, &test = %p\n", test, bsr, &test);
return 0;
}
and compiled it with various versions of gcc -O3 ... to the following results:
code generated gcc version
================================================================================
400630: 48 83 ec 18 sub $0x18,%rsp 4.7.2,
400634: 31 c0 xor %eax,%eax 4.6.2,
400636: bf 50 07 40 00 mov $0x400750,%edi 4.4.6
40063b: 48 8d 4c 24 08 lea 0x8(%rsp),%rcx
400640: 48 0f ba e8 27 bts $0x27,%rax
400645: 48 89 44 24 08 mov %rax,0x8(%rsp)
40064a: 48 89 c6 mov %rax,%rsi
40064d: 48 0f bd d0 bsr %rax,%rdx
400651: 31 c0 xor %eax,%eax
400653: e8 68 fe ff ff callq 4004c0
[ ... ]
---------------------------------------------------------------------------------
4004f0: 48 83 ec 18 sub $0x18,%rsp 4.1
4004f4: 31 c0 xor %eax,%eax
4004f6: bf 28 06 40 00 mov $0x400628,%edi
4004fb: 48 8d 4c 24 10 lea 0x10(%rsp),%rcx
400500: 48 c7 44 24 10 00 00 00 00 movq $0x0,0x10(%rsp)
400509: 48 0f ba e8 27 bts $0x27,%rax
40050e: 48 89 44 24 10 mov %rax,0x10(%rsp)
400513: 48 89 c6 mov %rax,%rsi
400516: 48 0f bd d0 bsr %rax,%rdx
40051a: 31 c0 xor %eax,%eax
40051c: e8 c7 fe ff ff callq 4003e8
[ ... ]
---------------------------------------------------------------------------------
400500: 48 83 ec 08 sub $0x8,%rsp 3.4.5
400504: bf 30 06 40 00 mov $0x400630,%edi
400509: 31 c0 xor %eax,%eax
40050b: 48 c7 04 24 00 00 00 00 movq $0x0,(%rsp)
400513: 48 89 e1 mov %rsp,%rcx
400516: 48 0f ba 2c 24 27 btsq $0x27,(%rsp)
40051c: 48 8b 34 24 mov (%rsp),%rsi
400520: 48 0f bd 14 24 bsr (%rsp),%rdx
400525: e8 fe fe ff ff callq 400428
[ ... ]
---------------------------------------------------------------------------------
4004e0: 48 83 ec 08 sub $0x8,%rsp 3.2.3
4004e4: bf 10 06 40 00 mov $0x400610,%edi
4004e9: 31 c0 xor %eax,%eax
4004eb: 48 c7 04 24 00 00 00 00 movq $0x0,(%rsp)
4004f3: 48 0f ba 2c 24 27 btsq $0x27,(%rsp)
4004f9: 48 8b 34 24 mov (%rsp),%rsi
4004fd: 48 89 e1 mov %rsp,%rcx
400500: 48 0f bd 14 24 bsr (%rsp),%rdx
400505: e8 ee fe ff ff callq 4003f8
[ ... ]
and while there's a significant difference in the created code (including whether the bsr acceesses test as register or memory), none of the tested revs recreate the assembly that you've shown. I'd suspect a bug in the 4.2.x version you used on MacOSX, but then I don't have either your testcase nor that specific compiler version available.
Edit: The code above is obviously different in the sense that it forces test into the stack; if that is not done, then all "plain" gcc versions I've tested do a direct pair bts $39, %rsi / bsr %rsi, %rdx.
I have found, though, that clang creates different code there: 140: 50 push %rax
141: 48 c7 04 24 00 00 00 00 movq $0x0,(%rsp)
149: 31 f6 xor %esi,%esi
14b: 48 0f ba ee 27 bts $0x27,%rsi
150: 48 89 34 24 mov %rsi,(%rsp)
154: 48 0f bd d6 bsr %rsi,%rdx
158: bf 00 00 00 00 mov $0x0,%edi
15d: 30 c0 xor %al,%al
15f: e8 00 00 00 00 callq printf#plt>so the difference seems to be indeed between the code generators of clang/llvm and "gcc proper".