View Issue Details

IDProjectCategoryView StatusLast Update
0000734Other Unix PortBugpublic2021-07-22 01:23
Reporteremax Assigned ToSteven Levine  
PrioritynormalSeverityblockReproducibilityrandom
Status resolvedResolutionno change required 
PlatformVbox guest VMOSeCSOS Version2.2b
Summary0000734: Stunnel 5.58 debug becomes unkillable
DescriptionSometimes, rarely, stunnel when becomes slow to answer popS requests (with high cpu load)
become unkillable

e.g. go -ka stunnel, killem stunnel etc.. and the server must be rebooted with setboot /b

Env: eCS2.2b VM under Vbox, VM with 1core and 3GB of ram assigned

Stunnel build:

https://smedley.id.au/tmp/stunnel-5.58-os2-20210414-debug.zip

Process dump (in the state of unresponsive and unkillable) in attachment
(result of: pdumpctl stunnel r f d o )

thanks

massimo
TagsNo tags attached.

Activities

emax

2021-05-22 01:38

reporter  

stunnel_dump.zip (594,289 bytes)

emax

2021-06-14 18:26

reporter  

stunnel_zombi_14_6_2021.zip (3,241,946 bytes)

emax

2021-06-14 18:36

reporter   ~0003739

today i had the same issue (14 jun 2021)
dump in attachment

emax

2021-06-16 21:19

reporter   ~0003740

same also today, this is becoming a serious issue, maybe more dangerous than the cpu overload

emax

2021-06-16 21:20

reporter   ~0003741

dump in attachment

Tom L

2021-06-18 23:30

reporter   ~0003744

I just want to confirm that I am seeing the same thing on my system. I'm using 5.58 to tunnel http traffic. At a random time, stunnel gets stuck in a way that it's thread will consume 100% of the CPU and the only way to kill it is to restart ArcaOS.

emax

2021-06-18 23:42

reporter   ~0003745

thanks a lot
i use "pdumpctl" to capture a dump of the "zombified" process with the command:

pdumpctl STUNNEL r f d o
and i upload it to mantis

the tool
PDumpCtl v0.16
 2020-01-31 SHL

is here:

http://www.warpcave.com/betas/
http://www.warpcave.com/betas/PDumpCtl-0.16-20200315.zip

Steven Levine

2021-06-19 00:34

manager   ~0003746

Tom, please open a separate ticket for your issue. While the symptoms may appear be the same, your issue may or may not have the same root cause.

If it turns out both you and Massimo are seeing the same issue, the tickets will be marked related in the fullness of time.

Another reason to open your own ticket is that sometimes tickets need to marked private and if this happens you will lose access.

Finally, I am not smart enough to keep track of the details for multiple configurations in a single ticket.

Steven Levine

2021-07-01 15:33

manager   ~0003770

The process dump indicates the hang is here.

# %kx
00a5fe58: Frame 00a5fe78 Ret _pthread_rwlock_trywrlock + 117
00a5fe78: Frame 00a5feb8 Ret CRYPTO_clear_free + af
00a5feb8: Frame 00a5fef8 Ret main_cleanup + 59
00a5fef8: Frame 00a5ff20 Ret main + a0
00a5ff20: Frame 00a5ff44 Ret text + 27
00a5ff44: Frame 00a5ffe0 Ret 1eeeed61
00a5ffe0: Frame 00000000 Ret 1efb449b
Can not access 0 - giving up

It also implies you may not be running an current version of the pthreads library. What version are you running? If it not the current version, please update and see if this is sufficient to resolve the hang.

emax

2021-07-02 02:00

reporter   ~0003771

trying to update (as always yum fail):

================================================================================Aggiornamento:
 pthread i686 2:0.2.4-1.oc00 netlabs-rel 16 k
Aggiornamenti per dipendenze:
 libc i686 1:0.1.7-1.oc00 netlabs-rel 1.0 M

Riepilogo della transazione
================================================================================Upgrade 2 Packages

Dimensione totale: 1.0 M
Dimensione totale del download: 16 k
Procedere [s/N]: s
Download dei pacchetti:
pthread-0.2.4-1.oc00 | 16 kB 00:00
Running Transaction Check
Test di transazione in corso


Errore nel controllo transazione:
  il file /@unixroot/usr/bin/pwd_mkdb.exe dell'installazione di libc-1:0.1.7-1.oc00.i686 entra in conflitto con il file del pacchetto klusrmgr-1.1.4-1.oc00.i686
Riepilogo errori
----------------

emax

2021-07-02 02:14

reporter   ~0003772

please delete note 3771 since i give the command on another server (the AOS 503 one)

instead on the right server if i give yum update yum update pthr01.dll
it say that will install 17 packages and update 27 packages
should i go?
is this safe?

thanks

Steven Levine

2021-07-02 06:17

manager   ~0003773


Did you really type:

  yum update yum update pthr01.dll

Is certainly not what I would type and it certainly not going to do what you expect. Did you even check if the list of packages to be updated made any sense?

If you are going to continue to refuse to use ANPM, you are going to have to put in the time to understand what yum actually does. As you have been told before, yum is a package installer. It is not a file installer.

To update the pthread package, the command is

  yum update pthread

Depending on what packages you currently have installed, this may need to update some dependent packages. Libc and libcx come to mind a possibilities.

Regarding your question about safety. If you actually knew how to use yum properly, my answer would probably be yes. In your case I recommend backing up in case you make a mistake. We know that yum packages rarely make changes outside of \usr \var and \etc, so you can probably safely get away with backing up just these directory trees, although a full backup might be better in your case.

emax

2021-07-10 00:54

reporter   ~0003788

ok, done
i updated pthread and yum also updated 27 packages and installed 17 :)
maybe a number of Dependencies :)

now pthreads dll is this:

Signature: @#bww bitwise works GmbH:0.2.4#@##1## 2021-03-09 15:10:52 Vendor: bww bitwise works GmbH
Revision: 0.02.4
Date/Time: 2021-03-09 15:10:52
Build Machine: novator
File Version: 0.2
Description: pthread implementation for OS/2

let's see if the issue happens again

thanks

emax

2021-07-22 01:05

reporter   ~0003827

hi all,

we can close this ticket
issue didn't happen again after the update of pthreads dll

thanks a lot

massimo

Steven Levine

2021-07-22 01:23

manager   ~0003828

Updating stale DLLs to current versions avoided traps and hangs.

Issue History

Date Modified Username Field Change
2021-05-22 01:38 emax New Issue
2021-05-22 01:38 emax File Added: stunnel_dump.zip
2021-06-14 18:26 emax File Added: stunnel_zombi_14_6_2021.zip
2021-06-14 18:36 emax File Added: stunnel_zombi_14_6_2021-2.zip
2021-06-14 18:36 emax Note Added: 0003739
2021-06-16 21:19 emax Note Added: 0003740
2021-06-16 21:20 emax Note Added: 0003741
2021-06-18 23:30 Tom L Note Added: 0003744
2021-06-18 23:42 emax Note Added: 0003745
2021-06-19 00:34 Steven Levine Note Added: 0003746
2021-07-01 15:00 Steven Levine Assigned To => Steven Levine
2021-07-01 15:00 Steven Levine Status new => assigned
2021-07-01 15:33 Steven Levine Status assigned => feedback
2021-07-01 15:33 Steven Levine Note Added: 0003770
2021-07-02 02:00 emax Note Added: 0003771
2021-07-02 02:00 emax Status feedback => assigned
2021-07-02 02:14 emax Note Added: 0003772
2021-07-02 06:17 Steven Levine Status assigned => feedback
2021-07-02 06:17 Steven Levine Note Added: 0003773
2021-07-10 00:54 emax Note Added: 0003788
2021-07-10 00:54 emax Status feedback => assigned
2021-07-22 01:05 emax Note Added: 0003827
2021-07-22 01:23 Steven Levine Status assigned => resolved
2021-07-22 01:23 Steven Levine Resolution open => no change required
2021-07-22 01:23 Steven Levine Note Added: 0003828