>(i'm using SPE to try to mitigate the 100% cpu load)
>of course when running idebug i must run directly stunnel.exe, i guess
>right?
Yes, I've updated idebug-stunnel-readme.txt to clarify this. There's a
copy of the update idebug-stunnel-readme.txt appended to this message.
>should i run stunnel under the debugger and wait until it overload the
>cpu? when it overload the cpu what i've to do?
Not yet, but eventually. See the updated step 6.6. It appears that the
debugger is not finding the source files yet, or I misunderstood your next
message.
2020-06-08 SHL Baseline
2020-07-07 SHL Update
2020-07-16 SHL Sync 6.3 with minor script changes
2020-07-16 SHL Add more details to 6.6
2021-03-26 SHL Expand scripts notes
2021-03-26 SHL Expand HelpDesk notes
== 1.0 Introduction ==
The idebug-small package is a set of scripts and files that allow an
application of be run under the VAC debugger without having a full VAC
3.65 development environment installed. The package is designed to be
run on systems where the user may have no developer skills and no
development tools installed.
This is the stunnel version of the idebug-small. It includes the
specific files needed to run stunnel under the VAC debugger on your
system.
When the user lacks the ability to use or to learn how to use the VAC
debugger, the debugger is typically run by a developer who will access
the user's system with the OS2Voice HelpDesk.
== 2.0 Requirements ==
The scripts are designed to be run under 4OS2, so you need 4OS2 available
on your system. If you don't already have 4OS2 installed, you can install
the version supplied with ArcaOS or any other relatively recent available
version.
The scripts require a small number of additional executables or scripts
that are available on most systems. The scripts check that these
required items are available and will alert you if something is missing.
If something unexpected is missing, the script will probably generate an
error message and you should report this to the developer so the issue can
be addressed.
You will need a copy of stunnel.exe built with debug data. The developer
will provide you will a copy, if needed.
If you are not capable of debugging the issue yourself, you will need to
run the OS2Voice HelpDesk client to allow the developer to access your
system and run the debugger for you. If you are not familiar with the
OS2Voice HelpDesk Tool, you must read and understand
and read an understand the included documentation.
The developer will provide you a configured copy of the HelpDesk client
that you will use to initiate the HelpDesk session.
== 3.0 Scripts ==
init-idebug.cmd Prepares system to run VAC debugger.
init-idebug-stunnel-massimo.cmd Prepares system to run stunnel under
the debugger.
== 4.0 Distributed files ==
idebug-stunnel-readme.txt This file.
idebug-small-yyyymmdd.zip VAC debugger package. These are the
scripts and binary files required run
the VAC 3.65 debugger on your system.
yyyymmdd will be the version timestamp of
the files you were provided.
stunnel-v.vv-src-yyyymmdd.zip Stunnel source files and scripts. These
are the scripts and source files needed to
run stunnel under the VAC debugger. v.vv
will be the stunnel version of the
stunnel sources and yyyymmdd will be the
timestamp of the zip file you were
provided.
== 5.0 Installation ==
To install the package, proceed as follows:
5.1 Create a work directory. It will be called \idebug here, but you can
name the directory whatever you want.
5.2 Unzip idebug-small-yyyymmdd.zip to the \idebug directory, preserving
paths.
5.3 Unzip stunnel-v.vv-src-yyyymmdd.zip to the \idebug directory
preserving paths.
5.4 You should end up with the following directory tree structure:
idebug\
src\
The idebug directory will contain the VAC debugger binaries and various
support scripts.
The src directory will contain the stunnel source files needed by the
debugger.
== 6.0 Testing your setup ==
6.1 Open a 4OS2 session with the \idebug directory as the current directory.
6.2 From the command line, enter
init-idebug.cmd
to set up the VAC debugger environment.
6.3 From the command line, enter
init-idebug-stunnel-massimo.cmd
to set up the VAC debugger environment for debugging stunnel. The
script checks that stunnel can be found in the PATH which is typical
for most installations. If this is not the case for your system, you
will get the warning:
Warning: cannot access stunnel in PATH
This may or may not be a problem on your system. Press enter to
continue and see the comments in step 6.6.
6.4 From the command line, enter
idebug
The debugger should start up and open the Startup Information dialog
window. If this occurs, press Esc to close the dialog window and
display the Debugger - Session Control window. Press F3 to terminate
the debugger.
If the debugger does not start as described, something is not
quite right with your setup. Ask for help before continuing.
6.5 From the command line, cd to the directory where you want to
run stunnel.
The paths contained in your stunnel.conf usually determine the
directory where you need to run stunnel. If your stunnel.conf contains
only absolute paths, the current directory should not matter, so there
should be no need to change the current directory.
If your stunnel.conf contains relative paths, you are probably going to
change to change the a current directory that works for these relative
paths.
The init-idebug.cmd and init-idebug-stunnel-massimo.cmd scripts set up
the environment so that the debugger should run correctly from any
directory.
6.6 From the command line, start the debugger and stunnel.
If stunnel.exe is in the current directory or is in the PATH and
stunnel.conf is in the current directory, use
idebug stunnel stunnel.conf
to start the debugger.
If the version of stunnel to be debugged is not in the current
directory or will not be found first in the PATH, be sure to specify
the full path to this version of stunnel on the command line.
If the version of stunnel.conf to be used is not in the current
directory, be sure to specify the full path to this version of
stunnel.conf on the command line.
For example, if the stunnel.exe and the stunnel.conf you want to use
are installed to X:\stunnel, use
If you have multiple copies of stunnel.exe installed on your system,
be sure that the the debugger will use the version that contains the
debug data.
The debugger should start up and show the Debugger - Session Control
window and a source window showing the current source file. This
source file should be UI_UNIX.C. If something else occurs, ask for
help before continuing.
If the debugger does not start as described, something is not
quite right with your setup. Ask for help before continuing.
Start stunnel under the debugger and verify that stunnel starts and
runs as to expected. To start stunnel, use The Run->Run menu item or
press the R hotkey or click the Run icon. Check to debugger's
Debug Appl window. It should show the typical stunnel console output.
If stunnel does not start as expected, check your command line
parameters. If you cannot get stunnel running correctly under the
debugger, ask for help before continuing.
Verify that the issue to be debugged can occur when running under the
debugger. If you have trouble doing this, ask for help before
continuing.
To stop stunnel, use the Run->Halt menu item or press the SysRq key or
click the Halt icon or press Ctrl-C in the Debug Appl window.
Once all of the above happens as described, you are ready the debug
your issue. If you are not going the debug stunnel yourself, press F3
to terminate the debugger. Otherwise, have at it and good luck.
== 7.0 Working with the developer ==
If you are not going to debug stunnel yourself, be prepared to explain
to the developer exactly how you start the stunnel instance that needs
to be debugged. This includes the working directory and the stunnel
command line and any other relevant information such as the
stunnel.conf file you are using along with any related files.
== 8.0 Running stunnel under the debugger ==
When running an stunnel instance under the debugger, you should be
able to continue to run other applications normally. This includes
other stunnel instances.
You need to ensure any fault daemons you have running will not
interfere with the stunnel instance begin debugged.
You need to ensure that the issue being debugged can occur.
The debugger may crash, but it normally will not take down the system.
However, nothing is perfect, so be prepared to reboot if needed.
listeye geri dön