3 Replies Latest reply: Jan 26, 2012 11:19 AM by Todd Little-Oracle RSS

    Debug a Tuxedo running server with dbx

    892247
      Hi all,

      I'm triying to debug a running tuxedo server with dbx, calling one of his services using a Java client. I've read (Re: gdb - debugging problem and Re: Debugging  of Tuxedo Service in C/C++ but I can't resolve my problem with them. This are the steps that I've followed:

      1) Start the server normally with tmboot:

      /aplicaciones/atos/CRPR_RESI/bin > tmboot -s ac_reAdmXaGesNegocioS_ext_V1000
      INFO: Oracle Tuxedo, Version 10.3.0.0, 64-bit, Patch Level (none)

      Booting server processes ...

      exec ac_reAdmXaGesNegocioS_ext_V1000 -A :
      process id=10813652 ... Started.
      1 process started.

      2) Copy the sorce file to the binary directory, so dbx can map the lines.
      3) Attach dbx to the PID of the server:

      /aplicaciones/atos/CRPR_RESI/bin > dbx -a 10813652
      Waiting to attach to process 10813652 ...
      Successfully attached to ac_reAdmXaGesNegocioS_ext_V1000.
      Type 'help' for help.
      reading symbolic information ...warning: ac_reAdmXaGestorNegociosS_ext.cpp is newer than ac_reAdmXaGesNegocioS_ext_V1000

      stopped in msgrcv at 0x9000000001d1a10 ($t1)
      0x9000000001d1a10 (msgrcv+0xb0) e8410028 ld r2,0x28(r1)
      (dbx)

      4) I don't know why it stops automatically to "msgrcv" ¿?. Anyway, I put an interruption point on the line when my service starts:

      (dbx) stop at 13930
      [1] stop at "ac_reAdmXaGestorNegociosS_ext.cpp":13930
      (dbx) list 13919, 13935
      13919 //{{IDL_HEADER(ac_re_ctrlversion_consulta)
      13920 void ac_re_ctrlversion_consulta::Implementation(
      13921
      13922 NAMESPACE(ac_resp_st_gestor_negocios_ext2)ac_re_st_ctrol_versiones filtro_entrada
      13923 , NAMESPACE(ac_resp_st_gestor_negocios_ext2)ac_re_st_ult_ctrol_versiones * estruct_paginado
      13924 , RPRInt16 * num_Items
      13925 , NAMESPACE(ac_resp_st_gestor_negocios_ext2)ac_re_st_ctrol_versiones * lista_regsalida
      13926 , RPRUbyte * pcHayMas
      13927 )
      13928 //}}IDL_HEADER(ac_re_ctrlversion_consulta)
      13929 {
      13930 Traza("**************INICIO DEL SERVICIO DE CONSULTA EN AC_CTRLVERSION*****************");
      13931 Traza("*******************************DECLARACIONES************************************");
      13932 RProcRAccess acc;
      13933 Cursor &c_consulta = *acc.GetCursor();
      13934 DateTime Fecha;
      13935
      (dbx)

      5) I call the service through the Java client, and the client hangs... waiting for the service. I do "steps" on dbx:

      (dbx) step

      User defined signal 1 in msgrcv at 0x9000000001d1a10 ($t1)
      0x9000000001d1a10 (msgrcv+0xb0) e8410028 ld r2,0x28(r1)
      (dbx) step
      stopped in Uintercept at 0x900000007ba2850 ($t1)
      0x900000007ba2850 (Uintercept) fbe1fff8 std r31,-8(r1)
      (dbx) step
      < in this point dbx frezees, the service and the Java client resumes >

      6) This is the truncated log of the service:

      [2012/01/24 11:48:31] Warning: no rpr_srv_version specified
      [2012/01/24 11:48:31] Service AC_RE_CONSULVER (IN) -<Size=4096,Version=-627632180,Flags=0>-
      [2012/01/24 11:48:31] #1 - RPR_NTVVAR= {..}
      [2012/01/24 11:48:31] #2 - RPR_NTVVAR= {..}
      [2012/01/24 11:48:31] #3 - RPR_SHORT=1
      ...
      [2012/01/24 11:48:31] Service AC_RE_CONSULVER (OUT) -<Size=1672,Version=-627632180,Flags=0>-
      [2012/01/24 11:48:31] #2 - RPR_NTVVAR= {..}
      [2012/01/24 11:48:31] #3 - RPR_SHORT=0
      [2012/01/24 11:48:31] #4 - RPR_NTVVAR= {..}
      [2012/01/24 11:48:31] #5 - RPR_CHAR=78

      7) I've to press CTRL + C on dbx:

      <CTRL + C>
      Interrupt in msgrcv at 0x9000000001d1a10 ($t1)
      0x9000000001d1a10 (msgrcv+0xb0) e8410028 ld r2,0x28(r1)
      (dbx)

      8) It goes normal again, and when I quit, the servers PID has changed, and the old one appears in the end of the servers command line behind the -R parameter. I don't know what it means:

      (dbx) quit
      /aplicaciones/atos/CRPR_RESI/bin > ps -ef | grep ac_reAdmXaGesNegocioS_ext_V1000
      atos 6860940 10399980 0 11:53:28 pts/15 0:00 grep ac_reAdmXaGesNegocioS_ext_V1000
      atos *7163938* 1 4 11:53:26 - 0:00 ac_reAdmXaGesNegocioS_ext_V1000 -C dom=RESI_DOMAIN_CSTR_EVR -g 5 -i 911 -u tdea3p02_maclan -U /aplicaciones/atos/CRPR_RESI/release/ULOG_AC_RE -m 0 -R 10813652
      /aplicaciones/atos/CRPR_RESI/bin >

      9) The service internal logic isn't correctly executed, when dbx is used, because there is no data on exit. But it works correctly without dbx attached.

      I think that I doing somenthing wrong (or many things wrong :)), but I'm lost at this point. Any advice will be appreciated.

      Thanks,
      Gabriel
        • 1. Re: Debug a Tuxedo running server with dbx
          Kristian Ivarsson
          Hi Gabriel,

          don't know if this qualifies as a Tuxedo related question and I'm a bit lost in all these lines, but ...

          ... when you attach dbx to a process it will become annexed by dbx (normal behaviour) and you're starting to go through the instructions (machine-code) by using 'step', but I would (probably) use 'cont(inue)' instead that give control to the process instead (depending of what you really wanna do)

          Good luck,
          Kristian
          • 2. Re: Debug a Tuxedo running server with dbx
            892247
            Hi Kristian,

            The cont instruction was what I needed, thank you!. Now I can step through the lines and watch variables:

            (dbx) cont
            [6] stopped in ac_re_ctrlversion_consulta::Implementation(ac_re_st_ctrol_versiones,ac_re_st_ult_ctrol_versiones*,short*,ac_re_st_ctrol_versiones*,unsigned char*) at line 13930 in file "ac_reAdmXaGestorNegociosS_ext.cpp" ($t1)
            13930 Traza("**************INICIO DEL SERVICIO DE CONSULTA EN AC_CTRLVERSION*****************");
            (dbx) step
            stopped in ac_re_ctrlversion_consulta::Implementation(ac_re_st_ctrol_versiones,ac_re_st_ult_ctrol_versiones*,short*,ac_re_st_ctrol_versiones*,unsigned char*) at line 13931 in file "ac_reAdmXaGestorNegociosS_ext.cpp" ($t1)
            13931 Traza("*******************************DECLARACIONES************************************");
            (dbx) step
            stopped in ac_re_ctrlversion_consulta::Implementation(ac_re_st_ctrol_versiones,ac_re_st_ult_ctrol_versiones*,short*,ac_re_st_ctrol_versiones*,unsigned char*) at line 13932 in file "ac_reAdmXaGestorNegociosS_ext.cpp" ($t1)
            13932 RProcRAccess acc;
            (dbx) step
            stopped in ac_re_ctrlversion_consulta::Implementation(ac_re_st_ctrol_versiones,ac_re_st_ult_ctrol_versiones*,short*,ac_re_st_ctrol_versiones*,unsigned char*) at line 13933 in file "ac_reAdmXaGestorNegociosS_ext.cpp" ($t1)
            13933 Cursor &c_consulta = *acc.GetCursor();
            (dbx) step
            stopped in ac_re_ctrlversion_consulta::Implementation(ac_re_st_ctrol_versiones,ac_re_st_ult_ctrol_versiones*,short*,ac_re_st_ctrol_versiones*,unsigned char*) at line 13934 in file "ac_reAdmXaGestorNegociosS_ext.cpp" ($t1)
            13934 DateTime Fecha;
            (dbx) step
            stopped in ac_re_ctrlversion_consulta::Implementation(ac_re_st_ctrol_versiones,ac_re_st_ult_ctrol_versiones*,short*,ac_re_st_ctrol_versiones*,unsigned char*) at line 13936 in file "ac_reAdmXaGestorNegociosS_ext.cpp" ($t1)
            13936 Traza("***************************ASIGNACION DE QUERYS*********************************");
            (dbx) print Fecha
            (dttm = (julday = 0, milsec = 0))

            Thanks again!

            Gabriel.
            • 3. Re: Debug a Tuxedo running server with dbx
              Todd Little-Oracle
              Hi Gabriel,

              Please keep in mind though that Tuxedo times requests and services, so you need to watch for exceeding BLOCKTIME and SVCTIMEOUT. Exceeding the former will cause the client to receive a TPETIME error, even if the server eventually tries to return successfully. Exceeding SVCTIMEOUT will cause your server to be killed by Tuxedo. So when debugging it is helpful to increase those values substantially, or at least be aware of what happens when you exceed those timeouts due to sitting in the debugger.

              Regards,
              Todd Little
              Oracle Tuxedo Chief Architect