|
Notes |
(0004560)
David McKenna
2022-09-06 21:13
|
I captured some ndpsmb log files on the client while browsing the SAMBA share - I'll upload. Went back and forth from a command line window and a WPS window. At 16:45 the command line window started giving the sys008 error (almost right away). The WPS window started showing some known full directories as '0 files' at 16:48. I stopped collecting log data once the WPS windows always said '0 files' and the command prompt always showed sys0008. |
|
(0004561)
David McKenna
2022-09-06 21:18
|
Forgot one... |
|
(0004562)
David McKenna
2022-09-06 21:24
|
I didn't explicitly mention that both the Server and client are running on ArcaOS 5.0.7 computers. Have not tested any other OS yet. |
|
(0004650)
psmedley
2024-01-02 06:36
|
Latest info from https://www.os2world.com/forum/index.php/topic,3515.30.html confirms that this only occurs with a share which is a whole drive - ie c:/ |
|
(0004652)
psmedley
2024-01-05 06:37
|
This *appears* to be related to some timeout issues we were seeing with the client with browsing a directory with a large number of files.
By default, samba commands have a 20 second timeout - increasing it to 60 seconds allowed a directory listing of a large folder (6 directories and over 2500 files for over 22GB of data) to succeed - and anecdotally, seems to have prevented the issues above.
I'll take a look at implementing some better error handling in the client for this (ie to detect the timeout). Interestingly, smbclient reports:
NT_STATUS_INVALID_NETWORK_RESPONSE listing \software\os2\*
smb: \software\os2\> SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The connection is disconnected now. |
|
(0004653)
David McKenna
2024-01-05 20:59
|
Attached are 2 log files requested. In both cases, all I did was start the server, then from the client, used the WPS to list the contents of the root of the share. 411logs.zip are the logs when running the 4.11.06 server, 418logs.zip are the logs when running the 4.18.9 server. Using 4.18 client for both. |
|
(0004657)
David McKenna
2024-01-13 13:14
|
Paul,
I attached the logs you requested. Started the NDFS control program using the 4.19 client attached to the 4.19 server. I got '0 files' browsing using the WPS at 8:06AM, then immediately checked on command line and also got the 'out of memory' error. Hope this helps... |
|
(0004658)
psmedley
2024-01-13 21:50
|
First observation is that you have an enormous quantity of log lines like the following in log.smbc, which don't seem to be 'normal' (he says having not checked his own):
[2024/01/13 08:04:08.291000, 5] ../../libcli/smb/smb2_signing.c:574(smb2_signing_sign_pdu)
signed SMB2 message (sign_algo_id=2)
Something like 33873 entries in a 76700 line log file.
log.smbc also shows what 'might' be the error that's getting reported to the client:
[2024/01/13 08:06:45.934000, 3] ../../source3/libsmb/clierror.c:91(cli_status_to_errno)
cli_status_to_errno: 0xc0000017 -> 12
the errno of 12 maps to ENOMEM which is an out of memory error - https://android.googlesource.com/kernel/lk/+/dima/for-travis/include/errno.h#45
More after a beach walk :) |
|
(0004659)
psmedley
2024-01-14 00:22
|
It may be interesting to confirm this is indeed a SMB2 issue.
On the server, add the following to smb.conf:
server min protocol = NT1
On the client:
client max protocol = NT1 |
|
(0004660)
psmedley
2024-01-14 02:21
|
OK, for the first time I was able to reproduce this. Seems to be triggered using the WPS to open large folders. General browsing from the command line doesn't do it. |
|
(0004661)
psmedley
2024-01-14 04:56
(Last edited: 2024-01-14 08:41) |
Does https://smedley.id.au/tmp/ndpsmb.zip help at all?
Edit: it breaks opening files via the WPS. It may still be interesting to see if you can trigger the out of memory error browsing via the WPS
Edit2: It doesn't actually break it, it was just really slow cos of the massive number of files in the directory I was opening from.
|
|
(0004662)
David McKenna
2024-01-14 13:31
|
I tried this ndpsmb.zip, but I can't seem to copy to the server with it. I can browse and open files though. Setting the server to 'server min protocol = NT1' doesn't seem to help either. Same behaviors as before...
On a different note, I notice that files on the server over 2GB in size always display as 2GB in the WPS. On the command line they show the correct size. Files on a local drive over 2GB show the correct size in the WPS too. Is that to be expected? |
|
(0004663)
LewisR
2024-01-14 20:07
|
Hi, David...
This is a known (by us) WPS bug. Have a quick look at Julien's ticket in the AN bugtracker, here:
https://mantis.arcanoae.com/view.php?id=2323
Whether it is fixable (and distributable by AN) or not remains unknown (under investigation).
As for not being able to copy to the server, do you have some log entries from either side? You might want to ensure that packet signing is off, as well, as I've seen issues with mandatory packet signing under SMB1 (unrelated to the OS/2 client or server). Packet signing cannot be disabled for SMB2, but for SMB1, on the server side, in the global stanza of smb.conf, set the following:
server signing = disabled
and restart the server. Unless the client side is set to mandatory, it should In fact, you might want to disable signing on the client side for this SMB1 testing, as well. Again, in the global stanza, set:
client signing = disabled
and restart the NetDrive control program.
Thanks for testing all of this and providing such great feedback. |
|
(0004664)
psmedley
2024-01-14 21:28
|
As Lewis said, 2gb limit in WPS is known. I'll have a look and see how I could have introduced an issue with copying files to the server, but are you able to reproduce the out of memory condition through browsing via the WPS? |
|
(0004665)
David McKenna
2024-01-14 23:29
|
Using the smb.conf directives Lewis requested (and keeping the NT1 ones as well), I reloaded the test ndpsmb.dll on the client and I have not had the '0 files' condition appear for 15 minutes (a long time!) while browsing the share. But it hardly matters, because I can't do anything else - no copy or open of files, or play mp3 or read txt files. When I try, it eventually leads to a WPS hang. At least the original 4.19 client could be used for awhile. (EDIT: while typing this, I got the out of memory error with the test ndpsmb.dll).
I have tried the original 4.19 client in a Virtual Box install on a Windows host, and have not yet got the out of memory condition (2 days now). But I also don't have any trouble using the share with Windows either.
Have also tried the 4.19 client on my ArcaOS laptop and there I eventually get WPS hangs, and the command line will show 'directory not found' errors instead of 'out of memory'. The laptop is attaching to the network via a travel router.
Also, smbclient does not work anywhere if I don't add -t 60 to the command - it always times out no matter where it is run.
I noticed in one of the server logs that there were 'broken extended attributes' on some directories (in particular \software and \software\os2, 2 of the largest) and files on the share. I tried to run eaclean on the drive, but it immediately crashed. This makes me nervous about the health of the drive (even though it chkdsk's without error) so I got a new one and will replace it - probably tomorrow. I attach the log that shows the error and a random file it claims has broken extended attributes. |
|
(0004666)
psmedley
2024-01-15 08:11
|
Probably need to zip the defective file as the EA's will have been lost with the upload here...
I'll have another think about the OOM error... |
|
(0004667)
David McKenna
2024-01-15 13:27
|
OK, I 7zipped the same file and attached. I tried just zip, but it would fail with a message: 'Interrupted (abort)'. Hope 7zip preserves EA's. |
|
(0004668)
David McKenna
2024-01-15 13:31
|
I wonder if it would be of any help to capture a TCP/IP trace while browsing for inspection in Wireshark? I could do it with the 4.11, then the 4.19 server running to see if there is any extraneous traffic being created to slow things down.... |
|
(0004669)
psmedley
2024-01-18 08:31
|
OK so the messages like:
os2getxattr : (software:0) user.DOSATTRIB 56
os2getxattr : (null:45) system.posix_acl_access -1
os2getxattr : (software:0) system.posix_acl_default -1
os2getxattr : (null:45) user.DOSATTRIB -1
os2getxattr : (null:45) user.DOSATTRIB -1
os2getxattr : (software/.:0) user.DOSATTRIB 56
os2listxattr: path software/., file 0 at libattr/syscalls.c(290)
Broken Extended Attributes detected for: software/.:0, Last EA:
Come from libattr, here, I can read odinapp.zip's EA's just fine. Weird. |
|
(0004682)
psmedley
2024-01-22 08:32
|
I don't suspect it will make a difference, but can you test with https://smedley.id.au/tmp/ndpsmb-20240122.zip |
|
(0004683)
David McKenna
2024-01-22 11:24
|
Unfortunately it does not help the 'out of memory' problem. |
|
(0004688)
psmedley
2024-01-24 08:39
|
OK - so the first out of memory seems to be:
[2024/01/23 09:38:27.270000, 5] ../../source3/smbd/files.c:1985(file_free)
file_free: freed files structure 0 (1 used)
[2024/01/23 09:38:27.270000, 5] ../../source3/smbd/files.c:77(fsp_new)
fsp_new: allocated files structure (2 used)
[2024/01/23 09:38:27.270000, 5] ../../source3/smbd/files.c:179(file_new)
file_new: new file fnum [invalid value]
[2024/01/23 09:38:27.270000, 5] ../../source3/smbd/files.c:321(openat_internal_dir_from_pathref)
openat_internal_dir_from_pathref: fd_openat(".", ".") failed: NT_STATUS_NO_MEMORY
[2024/01/23 09:38:27.270000, 5] ../../source3/smbd/files.c:1985(file_free)
file_free: freed files structure 0 (1 used)
[2024/01/23 09:38:27.270000, 3] ../../source3/smbd/filename.c:319(get_real_filename_full_scan_at)
get_real_filename_full_scan_at: scan dir didn't open dir [.]: NT_STATUS_NO_MEMORY
[2024/01/23 09:38:27.270000, 5] ../../source3/smbd/files.c:1985(file_free)
file_free: freed files structure 0 (0 used)
[2024/01/23 09:38:27.270000, 3] ../../source3/smbd/smb2_server.c:4033(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NO_MEMORY] || at ../../source3/smbd/smb2_create.c:360 |
|
(0004694)
David McKenna
2024-01-29 21:27
|
The client version ndpsmb-20240127 no longer has the 'out of memory' issue (been using it a couple of days now). This ticket can be closed - thanks! |
|
(0004695)
psmedley
2024-01-29 21:57
|
Latest client plugin resolves this |
|
|
Notes |
(0004336)
Steven Levine
2022-05-22 03:52
|
The reported traps are quite interesting. The exceptq report points us to
ext\mysqlnd\mysqlnd_connection.c:2441
MYSQLND_INC_CONN_STATISTIC(conn->stats, close_type_to_stat_map[close_type]);
MYSQLND_METHOD(mysqlnd_conn, close). The way I read the code generated by MYSQLND_INC_CONN_STATISTIC, the trap occurs when the code attempts to read the collect_statistics variable, which is stored in the Thread Local Storage provided by emutls. The trap occurs because the pointer to the Thead Local Storage is zero and
this should not occur.
It is not yet clear whether the pointer never got initialized or if it was released too soon. MYSQLND_METHOD(mysqlnd_conn, close) is closing the connectiion, but it's possible that it is closing a connection that never was completely setup.
Another interest feature of these traps is that they are reported for TID 1 which is rather unlikely for a thread running PHP code. PHP code only runs on worker threads. Threads 1 and 2 are management threads. I don't know why it happened, but it appears the trap occurred on some other thread and
got dispatched to thread 1 for processing. |
|
(0004337)
Steven Levine
2022-05-22 03:58
|
Please update your apache httpd installation. According to the exceptq report, you are running a mix of older distributions.
HTTPD 1eaa0000 000f16e0 05/08/2022 05:03:10 1,220,522 D:\APACHE\BIN\HTTPD.DLL
AUTHZ_GR 1ea60000 00002a40 06/19/2021 00:59:16 51,391 D:\APACHE\MODULES\AUTHZ_GR.DLL
This may have nothing to do with the traps, but we won't know until you clean up the install. Be sure to install.
https://smedley.id.au/tmp/httpd-2.4.53-os2-debug-20220511.zip
The httpd.dll you have installed is a retail build and does not have debug symbols. You should never install a retail build while you have open tickets. The exceptq reports will be hard work use.
|
|
(0004338)
psmedley
2022-05-22 10:02
|
I don't expect it will help, but https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220522.zip fixes some warnings whilst building mysqlnd |
|
(0004339)
emax
2022-05-22 16:14
|
updated apache to build https://smedley.id.au/tmp/httpd-2.4.53-os2-debug-20220511.zip
i never do 2 updates at the same time, so the update to php will come in the next days
(in case of issues is difficult to undestand which is the cause)
thanks |
|
(0004340)
Steven Levine
2022-05-22 18:28
|
Feel free to take as long as you need to apply the updates. It's only your system that seems to be affected by this trap.
I would like to know what is loaded at 1E0700BA on your current setup since it matches the setup at the time the traps were reported. The exceptq report implies that by the time the report was written the DLL at that address had unloaded. This is why the stack trace is incomplete.
If you don't have a copy of http://www.warpcave.com/os2diags/theseus-how-to.txt, grab one and use the section titled:
How to describe a linear address
Select the httpd process from the Process hierarchy and follow the directions and upload the saved file. Thanks.
|
|
(0004341)
emax
2022-05-22 19:00
|
i've taken the output for main (mother) httpD and one child httpD |
|
(0004342)
Steven Levine
2022-05-23 02:16
|
I now understand how we got to the trapping location. It's essentially a timing race.
sapi\apache2handler\sapi_apache2.c:761
static void php_apache_child_init(apr_pool_t *pchild, server_rec *s)
registers
sapi\apache2handler\sapi_apache2.c:419
static apr_status_t php_apache_child_shutdown(void *tmp)
as the pool cleanup function. When pool is destroy, the pool cleanup function eventually calls
php_mysqli_dtor which eventually calls
ext\mysqlnd\mysqlnd_connection.c:2425
MYSQLND_METHOD(mysqlnd_conn, close)(MYSQLND * conn_handle, const enum_connection_close_type close_type)
which traps because the shutdown occurred before mysqli was fully initialized.
Once Massimo gets everything updated to current levels, if the issue persists, we can implement a patch to avoid the trap. |
|
(0004343)
emax
2022-05-23 08:40
|
hi, i've an issue
this morting at 6 am (scheduled reboot) apache had issues to start and the VM hanged in the system is rebooting
what should i do?
do you suggest me to install the latest php build or to wait and see why this happen? |
|
(0004344)
emax
2022-05-23 10:37
|
sorry, i forgot logs etc.
but this seems to me a complete different issue than the one of mysqli |
|
(0004345)
Steven Levine
2022-05-23 15:58
|
The exceptq reports imply that it is the same core issue. Php is attempting an early shutdown in response to some error it detected and not all the data php uses is fully initialized.
Perhaps I was not clear. I will not be attempting to implement fixes for any of your reported issues until you have found the time to update everything involved to current versions. I will review the reports to keep up with what's happened.
BTW, if you have made any changes to your httpd .conf files or your php .ini files, I need fresh reference copies.
Another BTW, you have your VM configured as:
Physical Memory: 3071 mb
Virt Addr Limit: 1536 mb
You are basically wasting 1.5GB of memory that the host system could find better uses for. |
|
(0004346)
emax
2022-05-23 20:15
|
php upgraded to build https://smedley.id.au/tmp/httpd-2.4.53-os2-debug-20220511.zip |
|
(0004347)
emax
2022-05-25 06:32
|
after this upgrade:
https://smedley.id.au/tmp/httpd-2.4.53-os2-debug-20220511.zip
i've serious issues, about once per day expecially at night (when i should sleep) i found the VM in state "guru meditation"
or completely freezed like some minutes ago
normally when the "guru meditation" state happens in VBOX is the vm using too much memory
i'm concerned and confused
please let me know what you need |
|
(0004348)
emax
2022-05-25 07:45
|
from apache error log i'm seeing again some of these, also on startup:
[Wed May 25 08:25:30.369000 2022] [mpm_mpmt_os2:notice] [pid 66:tid 1] AH00206: Apache/2.4.53 (OS/2) OpenSSL/1.1.1o PHP/7.4.28 configured -- resuming normal operations
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
wsistem/wp-login.php' not found or unable to stat, referer: http://newsistem.it/wp-login.php
[Wed May 25 08:28:45.273000 2022] [negotiation:error] [pid 67:tid 31] [client 113.78.66.156:1214] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated)., referer: http://sitepitalia.it/
[Wed May 25 08:29:59.023000 2022] [php7:error] [pid 69:tid 8] [client 165.227.129.197:60376] script 'D:/apache/htdocs/max/raffaellopiotto/wp-login.php' not found or unable to stat, referer: http://raffaellopiotto.it/wp-login.php
[Wed May 25 08:32:25.312000 2022] [php7:error] [pid 71:tid 30] [client 158.69.192.143:41384] script 'D:/apache/htdocs/max/mareemonti/wp-login.php' not found or unable to stat, referer: http://mareemonti.it/wp-login.php
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
[Wed May 25 08:36:46.832000 2022] [negotiation:error] [pid 68:tid 3] [client 49.146.46.148:49464] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated)., referer: https://www.google.com/
[Wed May 25 08:40:31.158000 2022] [php7:error] [pid 226:tid 15] [client 82.223.216.165:36538] script 'D:/apache/htdocs/max/ilvialedivaleria/wp-login.php' not found or unable to stat, referer: http://ilvialedivaleria.it/wp-login.php |
|
(0004349)
emax
2022-05-25 10:10
|
from apache error log i'm seeing again some of these, also on startup:
[Wed May 25 08:25:30.369000 2022] [mpm_mpmt_os2:notice] [pid 66:tid 1] AH00206: Apache/2.4.53 (OS/2) OpenSSL/1.1.1o PHP/7.4.28 configured -- resuming normal operations
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
wsistem/wp-login.php' not found or unable to stat, referer: http://newsistem.it/wp-login.php
[Wed May 25 08:28:45.273000 2022] [negotiation:error] [pid 67:tid 31] [client 113.78.66.156:1214] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated)., referer: http://sitepitalia.it/
[Wed May 25 08:29:59.023000 2022] [php7:error] [pid 69:tid 8] [client 165.227.129.197:60376] script 'D:/apache/htdocs/max/raffaellopiotto/wp-login.php' not found or unable to stat, referer: http://raffaellopiotto.it/wp-login.php
[Wed May 25 08:32:25.312000 2022] [php7:error] [pid 71:tid 30] [client 158.69.192.143:41384] script 'D:/apache/htdocs/max/mareemonti/wp-login.php' not found or unable to stat, referer: http://mareemonti.it/wp-login.php
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
mmap() failed: [12] Not enough memory
[Wed May 25 08:36:46.832000 2022] [negotiation:error] [pid 68:tid 3] [client 49.146.46.148:49464] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated)., referer: https://www.google.com/
[Wed May 25 08:40:31.158000 2022] [php7:error] [pid 226:tid 15] [client 82.223.216.165:36538] script 'D:/apache/htdocs/max/ilvialedivaleria/wp-login.php' not found or unable to stat, referer: http://ilvialedivaleria.it/wp-login.php |
|
(0004350)
emax
2022-05-25 10:31
|
apache become unresponsive about around 8:20 AM
but i guess the issue started at 8:06
i will not upload apache error log since it's (incredible for me) only full of point chars, eg.:
................ .........
............................................................................................................................... .........
02f1 and 02f2 are the 2 eQ dumps in apache dir
in var-log-app i've 59 eQ dumps from 8:06
i'm going to upload only first and last, let me know if you need other
thanks |
|
(0004351)
Steven Levine
2022-05-26 00:26
|
I have no idea how I managed to make my note comment go into the bit bucket rather than the ticket, but it did. Repeating myself...
The system definitely found a way to run out of available address space.
The tickets don't provide a lot of hints how the system got to this state.
It would have been good if you remembered to capture a Private Object Summary and
Shared Object summary for the process that reported the mmap failures.
A Linear Memory Map might also have provided some useful clues (System ->
General System -> Linear usage by process).
When you get all the httpd and php binaries updated to current version, we
can resume working on your httpd and php tickets. |
|
(0004354)
emax
2022-05-26 07:45
|
Steven, i'm running:
this https://smedley.id.au/tmp/httpd-2.4.53-os2-debug-20220511.zip
and
this php-7.4.28-os2-debug-20220522.zip
i guess it's all updated, am i right?
(this 2 latest build have, sorry, but no good performances) |
|
(0004355)
Steven Levine
2022-05-26 16:01
|
When you ask "i guess it's all updated, am i right?" did it not not occur to you to actually check what you are running and look at the timestamps of the binaries. The information you need to check this in in every exceptq report and many other places.
Review the
DLLs accessible from this process
For php, your binaries should all be timestamped 2022-05-22. For httpd, your binaries should all be timestamped 2022-05-10 or newer.
I've mentioned this before, but since you seem to have forgotten, you need to adjust your procedure for installing binaries. Something you are doing is changing the hour, minutes and seconds in unexpected ways. It's more than a timezone shift which we all know how to recognize.
|
|
(0004356)
emax
2022-05-26 16:05
|
ok for the check
but, sorry, it's not easier to say apache: build and php build? |
|
(0004357)
emax
2022-05-26 16:26
|
i repeat when there is a new build i allways update my installation
as you know *i don't* make 2 upgrades at a time, since if a problem occurs it's difficult to understand
what cause the issue or not
i've first upgraded to latest debug apache: https://smedley.id.au/tmp/httpd-2.4.53-os2-debug-20220511.zip
after just one day to the latest debug php: https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220522.zip
the content of apache-modules is this, so yes, we can keep on, please
(the older DLLs are not present in the latest debug build, so this is out of my control)
11/05/22 6:56 49.775 124 a--- accespat.dll
19/06/21 0:59 50.146 124 a--- access_c.dll
11/05/22 6:57 47.304 124 a--- actions.dll
11/05/22 6:57 53.932 124 a--- alias.dll
11/05/22 6:56 45.567 124 a--- allowods.dll
11/05/22 6:56 45.370 124 a--- asis.dll
11/05/22 6:56 52.594 124 a--- authnche.dll
11/05/22 6:56 51.278 124 a--- authndbd.dll
11/05/22 6:56 39.550 124 a--- authndbm.dll
11/05/22 6:56 47.025 124 a--- authnile.dll
11/05/22 6:56 42.053 124 a--- authnnon.dll
11/05/22 6:56 50.262 124 a--- authnore.dll
19/06/21 0:59 50.701 124 a--- authn_co.dll
19/06/21 0:59 47.386 124 a--- authn_fi.dll
11/05/22 6:56 53.858 124 a--- authzdbd.dll
11/05/22 6:56 45.706 124 a--- authzdbm.dll
11/05/22 6:56 50.796 124 a--- authzile.dll
11/05/22 6:56 46.892 124 a--- authzner.dll
11/05/22 6:56 66.070 124 a--- authzore.dll
11/05/22 6:56 51.489 124 a--- authzost.dll
11/05/22 6:56 46.257 124 a--- authzser.dll
19/06/21 0:59 66.909 124 a--- authz_co.dll
19/06/21 0:59 51.391 124 a--- authz_gr.dll
19/06/21 0:59 52.232 124 a--- authz_ho.dll
19/06/21 0:59 46.480 124 a--- authz_us.dll
19/06/21 0:59 55.768 124 a--- auth_bas.dll
11/05/22 6:56 82.776 124 a--- auth_est.dll
11/05/22 6:56 70.050 124 a--- auth_orm.dll
11/05/22 6:56 50.577 124 a--- auth_sic.dll
11/05/22 6:56 90.371 124 a--- autoidex.dll
19/06/21 1:00 93.231 124 a--- autoinde.dll
11/05/22 6:56 49.469 124 a--- buffer.dll
22/05/22 13:00 126.885 124 a--- bz2.dll
11/05/22 6:56 159.861 124 a--- cache.dll
11/05/22 6:56 86.377 124 a--- cacheche.dll
11/05/22 6:56 84.013 124 a--- cacheisk.dll
11/05/22 6:56 66.830 124 a--- cgi.dll
11/05/22 6:56 66.920 124 a--- charsite.dll
22/05/22 13:00 3.588.412 124 a--- curl.dll
11/05/22 6:56 47.319 124 a--- data.dll
11/05/22 6:56 276.922 124 a--- dav.dll
11/05/22 6:56 145.655 124 a--- dav_fs.dll
11/05/22 6:56 71.679 124 a--- dav_lock.dll
11/05/22 6:56 62.713 124 a--- dbd.dll
11/05/22 6:56 133.210 124 a--- deflate.dll
11/05/22 6:56 48.762 124 a--- dialup.dll
11/05/22 6:57 50.398 124 a--- dir.dll
26/05/22 18:17 2.835 0 a--- dll.txt
11/05/22 6:56 48.699 124 a--- dumpio.dll
11/05/22 6:56 44.372 124 a--- echo.dll
11/05/22 6:56 46.585 124 a--- env.dll
22/05/22 13:00 131.837 124 a--- exif.dll
11/05/22 6:56 51.589 124 a--- expires.dll
11/05/22 6:56 64.456 124 a--- ext_fter.dll
11/05/22 6:56 61.473 124 a--- filter.dll
22/05/22 13:00 3.361.747 124 a--- gd.dll
22/05/22 13:00 76.988 124 a--- gettext.dll
11/05/22 6:56 63.911 124 a--- headers.dll
11/05/22 6:56 44.050 124 a--- hearteat.dll
11/05/22 6:56 67.867 124 a--- hearttor.dll
22/05/22 13:01 1.327.848 124 a--- iconv.dll
11/05/22 6:56 116.371 124 a--- include.dll
11/05/22 6:56 62.834 124 a--- info.dll
22/05/22 13:01 5.081.251 124 a--- intl.dll
11/05/22 6:56 60.511 124 a--- lbmeteat.dll
11/05/22 6:56 50.384 124 a--- lbmetess.dll
11/05/22 6:56 51.705 124 a--- lbmetfic.dll
11/05/22 6:56 50.300 124 a--- lbmetsts.dll
11/05/22 6:56 49.218 124 a--- logio.dll
11/05/22 6:56 83.147 124 a--- log_cfig.dll
19/06/21 1:00 85.249 124 a--- log_conf.dll
11/05/22 6:56 47.559 124 a--- log_dbug.dll
19/06/21 1:00 50.616 124 a--- log_fore.dll
11/05/22 6:56 50.057 124 a--- log_fsic.dll
11/05/22 6:56 54.505 124 a--- macro.dll
22/05/22 13:01 1.614.368 124 a--- mbstring.dll
11/05/22 6:56 4.083.736 124 a--- md.dll
11/05/22 6:56 61.963 124 a--- mime.dll
11/05/22 6:56 68.701 124 a--- mime_gic.dll
19/06/21 1:00 74.849 124 a--- mime_mag.dll
22/05/22 13:01 102.499 124 a--- modphp7.dll
22/05/22 13:01 16.990 124 a--- modphp7.map
22/05/22 13:01 3.118 124 a--- modphp7.xqs
22/05/22 13:01 372.415 124 a--- mysqli.dll
19/06/21 1:00 88.561 124 a--- negotiat.dll
11/05/22 6:57 89.612 124 a--- negotion.dll
22/05/22 13:01 608.159 124 a--- odbc.dll
22/05/22 13:01 1.220.490 124 a--- opcache.dll
22/05/22 13:00 3.114.988 124 a--- openssl.dll
22/05/22 13:01 148.144 124 a--- pdo_mysq.dll
22/05/22 13:01 3.081.794 124 a--- pdo_pgsq.dll
22/05/22 13:01 1.072.768 124 a--- pdo_sqli.dll
22/05/22 13:01 3.199.204 124 a--- pgsql.dll
11/05/22 6:56 286.446 124 a--- proxy.dll
11/05/22 6:56 141.966 124 a--- proxyajp.dll
11/05/22 6:56 117.667 124 a--- proxycer.dll
11/05/22 6:56 60.383 124 a--- proxycgi.dll
11/05/22 6:56 83.905 124 a--- proxyeck.dll
11/05/22 6:56 60.808 124 a--- proxyect.dll
11/05/22 6:56 49.549 124 a--- proxyess.dll
11/05/22 6:56 93.232 124 a--- proxyftp.dll
11/05/22 6:56 67.423 124 a--- proxynel.dll
11/05/22 6:56 56.588 124 a--- proxysgi.dll
11/05/22 6:56 83.562 124 a--- proxyttp.dll
11/05/22 6:56 44.414 124 a--- ratelmit.dll
22/05/22 13:01 341.277 124 a--- readline.dll
11/05/22 6:56 48.650 124 a--- refletor.dll
11/05/22 6:56 69.383 124 a--- remoteip.dll
19/06/21 0:59 58.711 124 a--- reqtimeo.dll
11/05/22 6:56 57.869 124 a--- reqtiout.dll
11/05/22 6:56 51.852 124 a--- request.dll
11/05/22 6:57 146.102 124 a--- rewrite.dll
11/05/22 6:56 102.563 124 a--- sed.dll
11/05/22 6:56 53.192 124 a--- sessidbd.dll
11/05/22 6:56 48.441 124 a--- sessikie.dll
11/05/22 6:56 63.765 124 a--- session.dll
11/05/22 6:56 53.100 124 a--- setenvif.dll
11/05/22 6:56 42.342 124 a--- slotmain.dll
11/05/22 6:56 54.916 124 a--- slotmshm.dll
11/05/22 6:56 56.738 124 a--- socacche.dll
11/05/22 6:56 49.759 124 a--- socacdbm.dll
11/05/22 6:56 58.133 124 a--- socacdis.dll
11/05/22 6:56 65.246 124 a--- socacmcb.dll
11/05/22 6:57 52.136 124 a--- speling.dll
11/05/22 6:56 3.332.664 124 a--- ssl.dll
11/05/22 6:56 63.940 124 a--- status.dll
11/05/22 6:56 54.417 124 a--- substute.dll
22/05/22 13:01 424.160 124 a--- tidy.dll
11/05/22 6:56 44.975 124 a--- uniqu_id.dll
11/05/22 6:57 48.836 124 a--- userdir.dll
11/05/22 6:56 53.120 124 a--- usertack.dll
19/06/21 1:00 53.727 124 a--- usertrac.dll
11/05/22 6:56 42.667 124 a--- version.dll
11/05/22 6:57 47.128 124 a--- vhostias.dll
19/06/21 1:00 52.045 124 a--- vhost_al.dll
11/05/22 6:56 61.160 124 a--- watchdog.dll
22/05/22 13:01 305.961 124 a--- xmlrpc.dll
22/05/22 13:01 2.587.207 124 a--- xsl.dll
22/05/22 13:01 2.620.182 124 a--- zip.dll
11/05/22 6:56 49.775 124 a--- accespat.dll
19/06/21 0:59 50.146 124 a--- access_c.dll
11/05/22 6:57 47.304 124 a--- actions.dll
11/05/22 6:57 53.932 124 a--- alias.dll
11/05/22 6:56 45.567 124 a--- allowods.dll
11/05/22 6:56 45.370 124 a--- asis.dll
11/05/22 6:56 52.594 124 a--- authnche.dll
11/05/22 6:56 51.278 124 a--- authndbd.dll
11/05/22 6:56 39.550 124 a--- authndbm.dll
11/05/22 6:56 47.025 124 a--- authnile.dll
11/05/22 6:56 42.053 124 a--- authnnon.dll
11/05/22 6:56 50.262 124 a--- authnore.dll
19/06/21 0:59 50.701 124 a--- authn_co.dll
19/06/21 0:59 47.386 124 a--- authn_fi.dll
11/05/22 6:56 53.858 124 a--- authzdbd.dll
11/05/22 6:56 45.706 124 a--- authzdbm.dll
11/05/22 6:56 50.796 124 a--- authzile.dll
11/05/22 6:56 46.892 124 a--- authzner.dll
11/05/22 6:56 66.070 124 a--- authzore.dll
11/05/22 6:56 51.489 124 a--- authzost.dll
11/05/22 6:56 46.257 124 a--- authzser.dll
19/06/21 0:59 66.909 124 a--- authz_co.dll
19/06/21 0:59 51.391 124 a--- authz_gr.dll
19/06/21 0:59 52.232 124 a--- authz_ho.dll
19/06/21 0:59 46.480 124 a--- authz_us.dll
19/06/21 0:59 55.768 124 a--- auth_bas.dll
11/05/22 6:56 82.776 124 a--- auth_est.dll
11/05/22 6:56 70.050 124 a--- auth_orm.dll
11/05/22 6:56 50.577 124 a--- auth_sic.dll
11/05/22 6:56 90.371 124 a--- autoidex.dll
19/06/21 1:00 93.231 124 a--- autoinde.dll
11/05/22 6:56 49.469 124 a--- buffer.dll
22/05/22 13:00 126.885 124 a--- bz2.dll
11/05/22 6:56 159.861 124 a--- cache.dll
11/05/22 6:56 86.377 124 a--- cacheche.dll
11/05/22 6:56 84.013 124 a--- cacheisk.dll
11/05/22 6:56 66.830 124 a--- cgi.dll
11/05/22 6:56 66.920 124 a--- charsite.dll
22/05/22 13:00 3.588.412 124 a--- curl.dll
11/05/22 6:56 47.319 124 a--- data.dll
11/05/22 6:56 276.922 124 a--- dav.dll
11/05/22 6:56 145.655 124 a--- dav_fs.dll
11/05/22 6:56 71.679 124 a--- dav_lock.dll
11/05/22 6:56 62.713 124 a--- dbd.dll
11/05/22 6:56 133.210 124 a--- deflate.dll
11/05/22 6:56 48.762 124 a--- dialup.dll
11/05/22 6:57 50.398 124 a--- dir.dll
26/05/22 18:17 2.835 0 a--- dll.txt
11/05/22 6:56 48.699 124 a--- dumpio.dll
11/05/22 6:56 44.372 124 a--- echo.dll
11/05/22 6:56 46.585 124 a--- env.dll
22/05/22 13:00 131.837 124 a--- exif.dll
11/05/22 6:56 51.589 124 a--- expires.dll
11/05/22 6:56 64.456 124 a--- ext_fter.dll
11/05/22 6:56 61.473 124 a--- filter.dll
22/05/22 13:00 3.361.747 124 a--- gd.dll
22/05/22 13:00 76.988 124 a--- gettext.dll
11/05/22 6:56 63.911 124 a--- headers.dll
11/05/22 6:56 44.050 124 a--- hearteat.dll
11/05/22 6:56 67.867 124 a--- hearttor.dll
22/05/22 13:01 1.327.848 124 a--- iconv.dll
11/05/22 6:56 116.371 124 a--- include.dll
11/05/22 6:56 62.834 124 a--- info.dll
22/05/22 13:01 5.081.251 124 a--- intl.dll
11/05/22 6:56 60.511 124 a--- lbmeteat.dll
11/05/22 6:56 50.384 124 a--- lbmetess.dll
11/05/22 6:56 51.705 124 a--- lbmetfic.dll
11/05/22 6:56 50.300 124 a--- lbmetsts.dll
11/05/22 6:56 49.218 124 a--- logio.dll
11/05/22 6:56 83.147 124 a--- log_cfig.dll
19/06/21 1:00 85.249 124 a--- log_conf.dll
11/05/22 6:56 47.559 124 a--- log_dbug.dll
19/06/21 1:00 50.616 124 a--- log_fore.dll
11/05/22 6:56 50.057 124 a--- log_fsic.dll
11/05/22 6:56 54.505 124 a--- macro.dll
22/05/22 13:01 1.614.368 124 a--- mbstring.dll
11/05/22 6:56 4.083.736 124 a--- md.dll
11/05/22 6:56 61.963 124 a--- mime.dll
11/05/22 6:56 68.701 124 a--- mime_gic.dll
19/06/21 1:00 74.849 124 a--- mime_mag.dll
22/05/22 13:01 102.499 124 a--- modphp7.dll
22/05/22 13:01 16.990 124 a--- modphp7.map
22/05/22 13:01 3.118 124 a--- modphp7.xqs
22/05/22 13:01 372.415 124 a--- mysqli.dll
19/06/21 1:00 88.561 124 a--- negotiat.dll
11/05/22 6:57 89.612 124 a--- negotion.dll
22/05/22 13:01 608.159 124 a--- odbc.dll
22/05/22 13:01 1.220.490 124 a--- opcache.dll
22/05/22 13:00 3.114.988 124 a--- openssl.dll
22/05/22 13:01 148.144 124 a--- pdo_mysq.dll
22/05/22 13:01 3.081.794 124 a--- pdo_pgsq.dll
22/05/22 13:01 1.072.768 124 a--- pdo_sqli.dll
22/05/22 13:01 3.199.204 124 a--- pgsql.dll
11/05/22 6:56 286.446 124 a--- proxy.dll
11/05/22 6:56 141.966 124 a--- proxyajp.dll
11/05/22 6:56 117.667 124 a--- proxycer.dll
11/05/22 6:56 60.383 124 a--- proxycgi.dll
11/05/22 6:56 83.905 124 a--- proxyeck.dll
11/05/22 6:56 60.808 124 a--- proxyect.dll
11/05/22 6:56 49.549 124 a--- proxyess.dll
11/05/22 6:56 93.232 124 a--- proxyftp.dll
11/05/22 6:56 67.423 124 a--- proxynel.dll
11/05/22 6:56 56.588 124 a--- proxysgi.dll
11/05/22 6:56 83.562 124 a--- proxyttp.dll
11/05/22 6:56 44.414 124 a--- ratelmit.dll
22/05/22 13:01 341.277 124 a--- readline.dll
11/05/22 6:56 48.650 124 a--- refletor.dll
11/05/22 6:56 69.383 124 a--- remoteip.dll
19/06/21 0:59 58.711 124 a--- reqtimeo.dll
11/05/22 6:56 57.869 124 a--- reqtiout.dll
11/05/22 6:56 51.852 124 a--- request.dll
11/05/22 6:57 146.102 124 a--- rewrite.dll
11/05/22 6:56 102.563 124 a--- sed.dll
11/05/22 6:56 53.192 124 a--- sessidbd.dll
11/05/22 6:56 48.441 124 a--- sessikie.dll
11/05/22 6:56 63.765 124 a--- session.dll
11/05/22 6:56 53.100 124 a--- setenvif.dll
11/05/22 6:56 42.342 124 a--- slotmain.dll
11/05/22 6:56 54.916 124 a--- slotmshm.dll
11/05/22 6:56 56.738 124 a--- socacche.dll
11/05/22 6:56 49.759 124 a--- socacdbm.dll
11/05/22 6:56 58.133 124 a--- socacdis.dll
11/05/22 6:56 65.246 124 a--- socacmcb.dll
11/05/22 6:57 52.136 124 a--- speling.dll
11/05/22 6:56 3.332.664 124 a--- ssl.dll
11/05/22 6:56 63.940 124 a--- status.dll
11/05/22 6:56 54.417 124 a--- substute.dll
22/05/22 13:01 424.160 124 a--- tidy.dll
11/05/22 6:56 44.975 124 a--- uniqu_id.dll
11/05/22 6:57 48.836 124 a--- userdir.dll
11/05/22 6:56 53.120 124 a--- usertack.dll
19/06/21 1:00 53.727 124 a--- usertrac.dll
11/05/22 6:56 42.667 124 a--- version.dll
11/05/22 6:57 47.128 124 a--- vhostias.dll
19/06/21 1:00 52.045 124 a--- vhost_al.dll
11/05/22 6:56 61.160 124 a--- watchdog.dll
22/05/22 13:01 305.961 124 a--- xmlrpc.dll
22/05/22 13:01 2.587.207 124 a--- xsl.dll
22/05/22 13:01 2.620.182 124 a--- zip.dll |
|
(0004358)
David McKenna
2022-05-26 17:47
|
Hi Massimo,
About a year ago (19/06/21 to be exact), Paul had to change the names of some of the dll's to avoid name clashes. So all of the dll's dated 19/06/21 are obsolete. But apparently, your httpd.conf file is still pointing at some of those files (based on your exceptq files), so you need to go thru httpd.conf and make sure all of your modules have the correct current dll name.
For example, vhost_al.dll is now vhostias.dll; usertrac.dll is now usertack.dll; reqtimeo.dll is now reqtiout.dll etc.
Regards, |
|
(0004359)
emax
2022-05-26 21:17
|
OMG
thanks a lot David, i recall now
i renamed manually the modules with the old filenames from apache 2.2.x
so now i was keeping a lot of obsolete modules
it has been like a surgical operation, but now all names in httpd.conf and DLLs files fixed
11/05/22 6:56 49.775 124 a--- accespat.dll
11/05/22 6:57 47.304 124 a--- actions.dll
11/05/22 6:57 53.932 124 a--- alias.dll
11/05/22 6:56 45.567 124 a--- allowods.dll
11/05/22 6:56 45.370 124 a--- asis.dll
11/05/22 6:56 52.594 124 a--- authnche.dll
11/05/22 6:56 51.278 124 a--- authndbd.dll
11/05/22 6:56 39.550 124 a--- authndbm.dll
11/05/22 6:56 47.025 124 a--- authnile.dll
11/05/22 6:56 42.053 124 a--- authnnon.dll
11/05/22 6:56 50.262 124 a--- authnore.dll
11/05/22 6:56 53.858 124 a--- authzdbd.dll
11/05/22 6:56 45.706 124 a--- authzdbm.dll
11/05/22 6:56 50.796 124 a--- authzile.dll
11/05/22 6:56 46.892 124 a--- authzner.dll
11/05/22 6:56 66.070 124 a--- authzore.dll
11/05/22 6:56 51.489 124 a--- authzost.dll
11/05/22 6:56 46.257 124 a--- authzser.dll
11/05/22 6:56 82.776 124 a--- auth_est.dll
11/05/22 6:56 70.050 124 a--- auth_orm.dll
11/05/22 6:56 50.577 124 a--- auth_sic.dll
11/05/22 6:56 90.371 124 a--- autoidex.dll
11/05/22 6:56 49.469 124 a--- buffer.dll
22/05/22 13:00 126.885 124 a--- bz2.dll
11/05/22 6:56 159.861 124 a--- cache.dll
11/05/22 6:56 86.377 124 a--- cacheche.dll
11/05/22 6:56 84.013 124 a--- cacheisk.dll
11/05/22 6:56 66.830 124 a--- cgi.dll
11/05/22 6:56 66.920 124 a--- charsite.dll
22/05/22 13:00 3.588.412 124 a--- curl.dll
11/05/22 6:56 47.319 124 a--- data.dll
11/05/22 6:56 276.922 124 a--- dav.dll
11/05/22 6:56 145.655 124 a--- dav_fs.dll
11/05/22 6:56 71.679 124 a--- dav_lock.dll
11/05/22 6:56 62.713 124 a--- dbd.dll
11/05/22 6:56 133.210 124 a--- deflate.dll
11/05/22 6:56 48.762 124 a--- dialup.dll
11/05/22 6:57 50.398 124 a--- dir.dll
26/05/22 23:13 2.322 0 a--- dir.txt
11/05/22 6:56 48.699 124 a--- dumpio.dll
11/05/22 6:56 44.372 124 a--- echo.dll
11/05/22 6:56 46.585 124 a--- env.dll
22/05/22 13:00 131.837 124 a--- exif.dll
11/05/22 6:56 51.589 124 a--- expires.dll
11/05/22 6:56 64.456 124 a--- ext_fter.dll
11/05/22 6:56 61.473 124 a--- filter.dll
22/05/22 13:00 3.361.747 124 a--- gd.dll
22/05/22 13:00 76.988 124 a--- gettext.dll
11/05/22 6:56 63.911 124 a--- headers.dll
11/05/22 6:56 44.050 124 a--- hearteat.dll
11/05/22 6:56 67.867 124 a--- hearttor.dll
22/05/22 13:01 1.327.848 124 a--- iconv.dll
11/05/22 6:56 116.371 124 a--- include.dll
11/05/22 6:56 62.834 124 a--- info.dll
22/05/22 13:01 5.081.251 124 a--- intl.dll
11/05/22 6:56 60.511 124 a--- lbmeteat.dll
11/05/22 6:56 50.384 124 a--- lbmetess.dll
11/05/22 6:56 51.705 124 a--- lbmetfic.dll
11/05/22 6:56 50.300 124 a--- lbmetsts.dll
11/05/22 6:56 49.218 124 a--- logio.dll
11/05/22 6:56 83.147 124 a--- log_cfig.dll
11/05/22 6:56 47.559 124 a--- log_dbug.dll
11/05/22 6:56 50.057 124 a--- log_fsic.dll
11/05/22 6:56 54.505 124 a--- macro.dll
22/05/22 13:01 1.614.368 124 a--- mbstring.dll
11/05/22 6:56 4.083.736 124 a--- md.dll
11/05/22 6:56 61.963 124 a--- mime.dll
11/05/22 6:56 68.701 124 a--- mime_gic.dll
22/05/22 13:01 102.499 124 a--- modphp7.dll
22/05/22 13:01 16.990 124 a--- modphp7.map
22/05/22 13:01 3.118 124 a--- modphp7.xqs
22/05/22 13:01 372.415 124 a--- mysqli.dll
11/05/22 6:57 89.612 124 a--- negotion.dll
22/05/22 13:01 608.159 124 a--- odbc.dll
22/05/22 13:01 1.220.490 124 a--- opcache.dll
22/05/22 13:00 3.114.988 124 a--- openssl.dll
22/05/22 13:01 148.144 124 a--- pdo_mysq.dll
22/05/22 13:01 3.081.794 124 a--- pdo_pgsq.dll
22/05/22 13:01 1.072.768 124 a--- pdo_sqli.dll
22/05/22 13:01 3.199.204 124 a--- pgsql.dll
11/05/22 6:56 286.446 124 a--- proxy.dll
11/05/22 6:56 141.966 124 a--- proxyajp.dll
11/05/22 6:56 117.667 124 a--- proxycer.dll
11/05/22 6:56 60.383 124 a--- proxycgi.dll
11/05/22 6:56 83.905 124 a--- proxyeck.dll
11/05/22 6:56 60.808 124 a--- proxyect.dll
11/05/22 6:56 49.549 124 a--- proxyess.dll
11/05/22 6:56 93.232 124 a--- proxyftp.dll
11/05/22 6:56 67.423 124 a--- proxynel.dll
11/05/22 6:56 56.588 124 a--- proxysgi.dll
11/05/22 6:56 83.562 124 a--- proxyttp.dll
11/05/22 6:56 44.414 124 a--- ratelmit.dll
22/05/22 13:01 341.277 124 a--- readline.dll
11/05/22 6:56 48.650 124 a--- refletor.dll
11/05/22 6:56 69.383 124 a--- remoteip.dll
11/05/22 6:56 57.869 124 a--- reqtiout.dll
11/05/22 6:56 51.852 124 a--- request.dll
11/05/22 6:57 146.102 124 a--- rewrite.dll
11/05/22 6:56 102.563 124 a--- sed.dll
11/05/22 6:56 53.192 124 a--- sessidbd.dll
11/05/22 6:56 48.441 124 a--- sessikie.dll
11/05/22 6:56 63.765 124 a--- session.dll
11/05/22 6:56 53.100 124 a--- setenvif.dll
11/05/22 6:56 42.342 124 a--- slotmain.dll
11/05/22 6:56 54.916 124 a--- slotmshm.dll
11/05/22 6:56 56.738 124 a--- socacche.dll
11/05/22 6:56 49.759 124 a--- socacdbm.dll
11/05/22 6:56 58.133 124 a--- socacdis.dll
11/05/22 6:56 65.246 124 a--- socacmcb.dll
11/05/22 6:57 52.136 124 a--- speling.dll
11/05/22 6:56 3.332.664 124 a--- ssl.dll
11/05/22 6:56 63.940 124 a--- status.dll
11/05/22 6:56 54.417 124 a--- substute.dll
22/05/22 13:01 424.160 124 a--- tidy.dll
11/05/22 6:56 44.975 124 a--- uniqu_id.dll
11/05/22 6:57 48.836 124 a--- userdir.dll
11/05/22 6:56 53.120 124 a--- usertack.dll
11/05/22 6:56 42.667 124 a--- version.dll
11/05/22 6:57 47.128 124 a--- vhostias.dll
11/05/22 6:56 61.160 124 a--- watchdog.dll
22/05/22 13:01 305.961 124 a--- xmlrpc.dll
22/05/22 13:01 2.587.207 124 a--- xsl.dll
22/05/22 13:01 2.620.182 124 a--- zip.dll |
|
(0004360)
David McKenna
2022-05-27 00:08
|
Looks good... hope the patient is cured :)
Regards, |
|
(0004361)
Steven Levine
2022-05-27 01:10
|
We will know more once the next exceptq report is captured.
FWIW, I did not see any obvious evidence that mixing httpd releases was the source of any of Massimo's current issues, but one never knows. We have had cases in that where this kind of mixing was the cause of the reported issue and the issue was resolved by upgrading the old build that he was not aware he was still running. |
|
(0004362)
emax
2022-05-27 13:03
|
i've an update, the situation seems further improved and this is very good
only 1 eQ dump
part of apache error log here:
[Fri May 27 04:40:13.436000 2022] [negotiation:error] [pid 2759:tid 24] [client 141.8.142.65:34322] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Fri May 27 04:42:02.518000 2022] [core:error] [pid 2728:tid 7] [client 42.236.10.79:45873] AH00082: an unknown filter was not added: includes
[Fri May 27 04:46:07.562000 2022] [core:error] [pid 2744:tid 24] [client 5.188.62.76:51334] AH00082: an unknown filter was not added: includes
[Fri May 27 04:46:26.435000 2022] [php7:error] [pid 2744:tid 25] [client 5.188.62.76:60394] script 'D:/apache/htdocs/max/ecodicom/login.php' not found or unable to stat, referer: https://www.ecodicom.net/
[Fri May 27 04:46:33.871000 2022] [core:error] [pid 2744:tid 32] [client 5.188.62.76:54322] AH00082: an unknown filter was not added: includes
[Fri May 27 04:51:37.006000 2022] [mpm_mpmt_os2:notice] [pid 3027:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 04:57:12.061000 2022] [mpm_mpmt_os2:notice] [pid 3026:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 04:57:28.347000 2022] [mpm_mpmt_os2:notice] [pid 3027:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 05:00:00.770000 2022] [php7:error] [pid 3030:tid 23] [client 184.168.100.18:46086] script 'D:/apache/htdocs/max/campodelvescovo/wikindex.php' not found or unable to stat
[Fri May 27 05:00:00.818000 2022] [php7:error] [pid 3029:tid 27] [client 184.168.100.18:46088] script 'D:/apache/htdocs/max/campodelvescovo/admin.php' not found or unable to stat
[Fri May 27 05:00:00.863000 2022] [php7:error] [pid 3026:tid 29] [client 184.168.100.18:46084] script 'D:/apache/htdocs/max/campodelvescovo/2index.php' not found or unable to stat
[Fri May 27 05:08:50.152000 2022] [negotiation:error] [pid 3215:tid 3] [client 141.8.142.65:38000] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Fri May 27 05:11:28.895000 2022] [negotiation:error] [pid 3246:tid 4] [client 185.191.171.22:7824] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Fri May 27 05:13:12.486000 2022] [mpm_mpmt_os2:notice] [pid 3231:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 05:22:43.836000 2022] [mpm_mpmt_os2:notice] [pid 3215:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 05:24:47.049000 2022] [mpm_mpmt_os2:notice] [pid 3215:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 05:25:36.690000 2022] [negotiation:error] [pid 3215:tid 8] [client 185.191.171.4:34698] AH00690: no acceptable variant: D:/apache/htdocs/max/sollevamentoshop/category
[Fri May 27 05:31:55.628000 2022] [mpm_mpmt_os2:notice] [pid 3247:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
Killed by SIGSEGV
pid=0x0de6 ppid=0x08d7 tid=0x0001 slot=0x0054 pri=0x0200 mc=0x0001 ps=0x0010
D:\APACHE\BIN\HTTPD.EXE
cs:eip=204f96c0:0000003a ss:esp=1ebcca82:20030000 ebp=007f0053
ds=0000 es=0000 fs=20030150 gs=0000 efl=00000000
eax=007ff968 ebx=1ffc9d7c ecx=007ff97c edx=007ff9a0 edi=20030000 esi=007fff7c
Creating 0DE6_01.TRP
Moved 0de6_01.TRP to C:\var\log\app\62906c58-0de6_01-HTTPD-exceptq.txt
to stat
[Fri May 27 05:52:32.747000 2022] [mpm_mpmt_os2:notice] [pid 3557:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 05:59:27.355000 2022] [php7:error] [pid 3560:tid 26] [client 40.77.167.69:22848] script 'D:/apache/htdocs/max/sollevamentoshop/carelo.php' not found or unable to stat
[Fri May 27 06:00:23.220000 2022] [php7:error] [pid 3560:tid 27] [client 157.55.39.74:51968] script 'D:/apache/htdocs/max/sollevamentoshop/carelo.php' not found or unable to stat
[Fri May 27 06:11:31.971000 2022] [negotiation:error] [pid 3560:tid 28] [client 207.46.13.189:56896] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Fri May 27 06:17:37.878000 2022] [mpm_mpmt_os2:notice] [pid 3835:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 06:18:05.918000 2022] [mpm_mpmt_os2:notice] [pid 3839:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 27 06:18:34.154000 2022] [mpm_mpmt_os2:notice] [pid 3838:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept |
|
(0004363)
Steven Levine
2022-05-27 16:38
|
Your os2krnl is a bit stale:
DOSCALLS 08/12/2017 09:35:27 870,880 C:\OS2KRNL
which corresponds to:
----- Output of: bldlevel.exe C:\os2krnl ---------------------------------------
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#IBM:14.201#@_SMP IBM OS/2 Kernel
Vendor: IBM
Revision: 14.201
File Version: 14.201
Description: _SMP IBM OS/2 Kernel
You should consider updating to 14.202. The fixes may not be relevant to your setup. but as we have found, one never knows until one tests.
Your gcc1.dll is very stale:
GCC1 1edb0000 00008950 02/01/2015 15:32:03 28,871 C:\USR\LIB\GCC1.DLL
The current pentium4 version is 9.2.0-5:
07-22-20 20:36 65,864 124 gcc1.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#bww bitwise works GmbH:9.2.0-5.oc00#@##1## 23 Jul 2020 06:26:24 novator::::0::@@GNU GCC Runtime
Vendor: bww bitwise works GmbH
Revision: 9.02.0-5.oc00
Date/Time: 23 Jul 2020 06:26:24
Build Machine: novator
File Version: 9.2
Description: GNU GCC Runtime
83a06ea5da6cf824625c4c81ab8ad7cd *gcc1.dll
You definitely need to update gcc1.dll with ANPM.
While you are at it, based on the somewhat stale testlog I have, you probably should update ANPM too.
Finally, please install the current version of testlog.exe and run a fresh testlog generic and upload a copy to the ticket.
re62906c58-0de6_01-HTTPD-exceptq.txt reports that exception occurred at:
Trap -> 1DA80700 PHP7 0001:00930700 mysqlnd_connection.c#2441 _mysqlnd_mysqlnd_conn_data_list_method_pub + 1506 0001:0092F1FA (U:\dev\php-7-os2\ext\mysqlnd\mysqlnd_connection.c)
You should recognize this as yet another occurrence of the trap that generated this ticket.
Now that your system is sufficiently updated for the moment, we can conclude that the stale DLLs were
not the only cause for the failed connections that triggered the trap. We will get back to work on releasing a fix. The fix will avoid the trap. However, since the connection died early, the user's request will fail.
I recommend you try to understand from the logs where the connections are originating from and why the connections are dying early. It should go without saying that if the the requesting user is a valid user, it would be better if the request did not fail.
|
|
(0004364)
emax
2022-05-27 19:11
|
yum update gcc1.dll
before:
gcc1.dll 28,871 15-02-01 15:32
after:
gcc1.dll 65,864 20-07-23 5:36
Signature: @#bww bitwise works GmbH:9.2.0-5.oc00#@##1## 23 Jul 2020 06:26:24 novator::::0::@@GNU GCC Runtime
Vendor: bww bitwise works GmbH
Revision: 9.02.0-5.oc00
Date/Time: 23 Jul 2020 06:26:24
Build Machine: novator
File Version: 9.2
Description: GNU GCC Runtime
about testlog i've sent the output in private email
thanks |
|
(0004365)
psmedley
2022-05-27 23:00
|
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220528.zip has a possibile fix for this, based on https://github.com/psmedley/php-os2/pull/20 |
|
(0004368)
emax
2022-05-28 08:22
|
upgraded to the latest php https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220528.zip
thanks
this night (before the upgrade) i had 2 guru meditation on the VM
let me know if this can be of interest
the 2nd guru meditation about me is quite interesting, i started the VM at about 7:40
and at about 8:35 AM (or maybe 8:31, 8:32) the fault daemon on the other server do a check each 5 minutes
this is apache error log vrom 7:40 to 8:31 (i've no eQ dumps or popuplog.os2 entries in this period of time)
[Sat May 28 07:40:50.118000 2022] [mpm_mpmt_os2:notice] [pid 65:tid 1] AH00206: Apache/2.4.53 (OS/2) OpenSSL/1.1.1o PHP/7.4.28 configured -- resuming normal operations
[Sat May 28 07:42:46.215000 2022] [php7:error] [pid 70:tid 11] [client 143.198.30.100:47994] script 'D:/apache/htdocs/max/malatestalegnami/wp-login.php' not found or unable to stat, referer: http://malatestalegnami.it
[Sat May 28 07:58:19.087000 2022] [negotiation:error] [pid 67:tid 30] [client 104.244.79.234:44269] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated)., referer: https://sitepitalia.it/
zend_mm_heap corrupted
000 2022] [negotiation:error] [pid 69:tid 18] [client 207.46.13.189:57216] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Sat May 28 08:12:49.525000 2022] [negotiation:error] [pid 66:tid 28] [client 156.146.36.79:5891] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Sat May 28 08:12:59.543000 2022] [negotiation:error] [pid 68:tid 28] [client 156.146.36.79:5802] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
zend_mm_heap corrupted
000 2022] [negotiation:error] [pid 66:tid 29] [client 156.146.36.79:5875] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Sat May 28 08:13:07.385000 2022] [negotiation:error] [pid 70:tid 30] [client 156.146.36.79:5885] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Sat May 28 08:26:41.723000 2022] [mpm_mpmt_os2:notice] [pid 448:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:26:41.725000 2022] [mpm_mpmt_os2:notice] [pid 446:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:26:41.727000 2022] [mpm_mpmt_os2:notice] [pid 449:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:29:51.883000 2022] [mpm_mpmt_os2:notice] [pid 447:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:29:52.047000 2022] [mpm_mpmt_os2:notice] [pid 446:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:29:51.891000 2022] [mpm_mpmt_os2:notice] [pid 448:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:29:51.889000 2022] [mpm_mpmt_os2:notice] [pid 450:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:31:55.659000 2022] [mpm_mpmt_os2:notice] [pid 449:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:31:55.667000 2022] [mpm_mpmt_os2:notice] [pid 448:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:31:55.670000 2022] [mpm_mpmt_os2:notice] [pid 450:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Sat May 28 08:31:55.674000 2022] [mpm_mpmt_os2:notice] [pid 447:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept |
|
(0004369)
Steven Levine
2022-05-28 18:00
|
I'm not sure I would call the guru meditations interesting, but we should probably try to make them go away. This will require a new ticket. In case you missed it in the logs, the underlying issue is:
zend_mm_heap corrupted
and this should be mentioned in ticket title. When this kind of heap corruption occurs, php shuts down the current worker process with exit(). This will abort all the active requests on this httpd child process. I'm a bit surprised there is not more in the logs.
What you need to do it try to figure out what httpd/php is doing when this occurs.
One problem to be handled is that the code is not very helpful. There are 15 occurances of the same error message, so it will take some effort to figure out which one we are seeing.
Do you have any idea how busy the failing httpd child process was when it died? Can your logging tell us how many threads it was running?
At this time, I don't think the
Resource temporarily unavailable
are related. They occurred 10 minutes later.
|
|
(0004370)
emax
2022-05-30 09:59
|
I guess guru meditation happens when VM is using "too much memory", i'm now trying to run it with 2,5GB ram instead of 3GB
let's wait some day more, but they seems to be gone
the host has only 16GB ram and runs 3 VM, but soon when i will replace server1, one of these 3 VM will be moved to the other
so there will be sufficient memory for just 2 VMs
in the weekend in apache error log i've see a number of these:
[Mon May 30 06:50:10.945000 2022] [mpm_mpmt_os2:error] [pid 96:tid 1] (OS 105)The previous ownership of this semaphore has ended. : Sem owner died pidSemaphoreOwner = 93, tidSemaphoreOwner = 1, ulRequestCount = 1 rc = 105 at ap_mpm_child_main #0
mmap()failed pid:71 tib:12: [12] Not enough memory (484)
Killed by SIGABRT
pid=0x0463 ppid=0x01fe tid=0x0001 slot=0x0069 pri=0x0200 mc=0x0016 ps=0x0017 D:\APACHE\BIN\HTTPD.EXE
Creating 0463_01.TRP
Moved 0463_01.TRP to C:\var\log\app\62948461-0463_01-HTTPD-exceptq.txt
_fmutex operation failed: LIBC Heap request
are these interesting/useful?
about
"Do you have any idea how busy the failing httpd child process was when it died? Can your logging tell us how many threads it was running?"
sorry, no, the server went down so there are any logs
i could only say that normally near 8,30 there is a bit of load since more or less is when offices open here and all open the websites
i also run an e-commerce |
|
(0004371)
Steven Levine
2022-05-30 16:08
(Last edited: 2022-05-30 16:25) |
As I stated in https://mantis.smedley.id.au/view.php?id=760#c4369, this issue need a new ticket. It is totally unrelated the subject of this ticket.
Also, you neglected to include the exceptq report. Please attach it to the new ticket.
I recommend you take a closer look at how you have you systems configured. I've mentioned this before. Since forever, as Silvan is wont to say, you have configured the quasarbbs with:
Physical Memory: 3071 mb
Virt Addr Limit: 1536 mb
As I explained, this means you only made about 1GB available to your applications. The other 1.5GB is unused by OS/2 applications although it may be used by drivers.
|
|
(0004374)
emax
2022-05-30 21:55
|
ok, thanks please give me the right name for the new ticket
(i'm having again the issue as in note https://mantis.smedley.id.au/view.php?id=760#c4343
and this is very serious issue for me, since the setboot /b do not reboot the VM in this situation) |
|
(0004375)
Steven Levine
2022-05-31 00:35
|
Let's go with the description:
httpd/php reports zend_mm_heap corrupted
This a variant on the failures we worked on for ticket 0000745, but the underlying trigger appears to be a bit different.
Make sure to include the build information for the httpd and php builds and upload the most recent exceptq report and copy the applicable comments from this ticket.
The reason setboot cannot reboot the system is most likely because there is not enough memory availabe for your fault daemon to run setboot. My deadman.exe probably would be able to reboot the system because it uses the DOS.SYS driver to initiate the reboot. However, the current deadman does not know how to detect the
zend_mm_heap corrupted
message in the httpd error log. Let me think about buidling a version that knows how to do this. The system would still need to reboot to recover, but the reboot would be unattended.
|
|
(0004403)
Steven Levine
2022-06-10 22:01
|
There have been no new occurrences of the mysqlnd trap with https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220528.zip and newer. Work on the unrelated heap corrupt issue has moved to #761. |
|
|
Notes |
(0003943)
emax
2022-02-25 14:10
|
Hi,
even after SESSID FIX
https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220225.zip
i still have an important number of these PHP7 crashes |
|
(0003944)
psmedley
2022-02-26 08:11
|
No guarantees, but can you try https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220226.zip |
|
(0003945)
emax
2022-02-26 11:21
|
thanks
installed |
|
(0003946)
emax
2022-02-27 13:22
|
Unfortunately the crashes still happen |
|
(0003947)
psmedley
2022-02-28 08:19
|
OK I have some ideas - in zend_virtual_cwd.c there is code for win32 (also used for OS/2) to handle paths with drive letters.Perhaps I've missed something in there.
Do these traps correlate with any known events? If I could reproduce locally it would be much easier to fix. |
|
(0003948)
emax
2022-02-28 08:47
|
it's very very very difficult to say which kind of php code or script creates PHP7 traps
maybe word press websites, maybe some old php custom website, maybe some new php custom website
e.g. i allmost have no FATAL error in php error log in the last 2 days
but i've a great number of warnings from some word press website, but i don't believe these are the source of the crashes
cron restart apache 5 times per day (mostly during night hours), since i've the suspect that the more it run, the most the issues come out |
|
(0003949)
psmedley
2022-03-03 21:48
|
Small tweak in https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220304.zip |
|
(0003950)
emax
2022-03-04 06:48
|
hi,
thanks, but after about 5 minutes of uptime apache crashed and system setboot/b
(i've just opened some php and wp website to test it, it seems also slower than prev builds)
had to revert back to https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220226.zip
i produced hundreds of popuplog.os2 entries, but no eQ dumps
in attachment |
|
(0003951)
Steven Levine
2022-03-04 08:30
|
If you looked at the content of the popuplog items,which are all the same, you would notice that they are your typical breakpoint exceptions.
As to why you cannot find the associated exceptq reports, I can only guess. It's possible they did not get generated, but this is rarely the case. For this to happen, the exception has to occur before any of the kLIBC or libcx exception handlers get installed.
I recommend you check again, just to be sure.
My standard proof of life tests work, so something more complex is causing your exceptions. |
|
(0003952)
psmedley
2022-03-04 08:36
|
@Steven any thoughts on the traps in https://mantis.smedley.id.au/view.php?id=745#c3946? |
|
(0003953)
emax
2022-03-04 18:46
|
Hi all,
sorry, i've the dumps..
they are not in \apache DIR, but they are in \var\log\app
i've 9 of these
Arg 0 : D:\apache\bin\httpd.exe
Arg 1 : -d d:\apache
Cur dir : D:\apache
CRT Module: LIBCN0 hmod=0x65b (C:\USR\LIB\LIBCN0.DLL)
__libc_logInit: addr 0x1ec0fbb8 iObj=0 offObj=0x4fbb8
Origin : libcx
LIBCx version : 0.7.2
LIBCx module : C:\USR\LIB\LIBCX0.DLL (hmod=0713)
Millsecond Timestamp.
| Thread ID.
| | Log Group (Asrt for assertions).
| | | File Name.
| | | | Line Number.
| | | | | Function Name.
v v v v v v
xxxxxxxx tt gggg file:line:function: message
002f6cff 01 Asrt shared.c:591:global_lock: Assertion failed: arc == NO_ERROR (105)
===== LIBCx resource usage =====
Reserved memory size: 2097152 bytes
Committed memory size: 131072 bytes
Heap size total: 130656 bytes
Heap size used now: 28164 bytes
ProcDesc structs used now: 11
FileDesc structs used now: 0
SharedFileDesc structs used now: 0
===== LIBCx global mutex info =====
mutex handle: 80010099
owner state: dead
owner PID: 028f (655)
owner TID: 45
request #: 1
===== LIBCx stats end =====
and 297 of these:
Opened log at 2022-03-04 07:41:43.33 (002f6d01 ms since boot)
Process ID: 0x2bb (699) Parent PID: 0x289 (649) Type: 2
Exe hmte : 0xc31 (D:\APACHE\BIN\HTTPD.EXE)
Arg 0 : D:\apache\bin\httpd.exe
Arg 1 : -d d:\apache
Cur dir : D:\apache
CRT Module: LIBCN0 hmod=0x65b (C:\USR\LIB\LIBCN0.DLL)
__libc_logInit: addr 0x1ec0fbb8 iObj=0 offObj=0x4fbb8
Origin : libcx
LIBCx version : 0.7.2
LIBCx module : C:\USR\LIB\LIBCX0.DLL (hmod=0713)
Millsecond Timestamp.
| Thread ID.
| | Log Group (Asrt for assertions).
| | | File Name.
| | | | Line Number.
| | | | | Function Name.
v v v v v v
xxxxxxxx tt gggg file:line:function: message
002f6d03 01 Asrt shared.c:214:shared_init: Assertion failed: arc == NO_ERROR (105)
and 199 of these:
Opened log at 2022-03-04 07:42:48.42 (00306b3d ms since boot)
Process ID: 0x3e8 (1000) Parent PID: 0x289 (649) Type: 2
Exe hmte : 0xc31 (D:\APACHE\BIN\HTTPD.EXE)
Arg 0 : D:\apache\bin\httpd.exe
Arg 1 : -d d:\apache
Cur dir : D:\apache
CRT Module: LIBCN0 hmod=0x65b (C:\USR\LIB\LIBCN0.DLL)
__libc_logInit: addr 0x1ec0fbb8 iObj=0 offObj=0x4fbb8
Origin : libcx
LIBCx version : 0.7.2
LIBCx module : C:\USR\LIB\LIBCX0.DLL (hmod=0713)
Millsecond Timestamp.
| Thread ID.
| | Log Group (Asrt for assertions).
| | | File Name.
| | | | Line Number.
| | | | | Function Name.
v v v v v v
xxxxxxxx tt gggg file:line:function: message
00306b41 01 Asrt shared.c:214:shared_init: Assertion failed: arc == NO_ERROR (105)
and 10 full eQ dumps in attachment |
|
(0003954)
Steven Levine
2022-03-04 19:42
|
Paul, re: https://mantis.smedley.id.au/view.php?id=745#c3952, did you seem my response to Massimo's "apache 2.4.52+php7.4.8 issues" off-line thread? If you wish, I can re-post the details here.
The short summary is that start_memory_manager is effectively not expecting zend_mm_init to ever fail, so we trap when it does. I recommended that we come up with a way to cleanly terminate the affected thread so that httpd itself does not terminate. |
|
(0003955)
psmedley
2022-03-04 20:55
|
Hey Steven - nope, looks like that one either didn't get here, or I inadvertently deleted it. Here would be the best place for it. |
|
(0003956)
Steven Levine
2022-03-04 21:37
|
This is a lightly edited extract of what I posted to the "apache 2.4.52+php7.4.8 issues" thread.
Can I assume we are talking about ticket 0000745?
If so, IMO, the SIGSEGV has nothing to do with eassert.
I need a diff to bring my 7.4.28 reference sources in sync with yours, but what I have is close enough to make some perhaps useful comments and save you some time.
First, while these traps are worth resolving, but they are not going to leave httpd stuck in the exit list which is what this thread seems to be about.
Looking at 621b5a78-0045_21-HTTPD-exceptq.txt, this
Trap -> 1DAF7053 PHP7 0001:009A7053 zend_alloc.c#1252
@_emalloc@4 + 3F 0001:009A7014 (U:\dev\php-7.4.28\Zend\zend_alloc.c)
occurs because
1DAF7053 >ADD ECX, [EAX+0x4] (0348 04)
and
EAX : 00000000 EBX : 00000009 ECX : 00000010 EDX : 00000001
Since the trap is in
TID: 21 (33)
we know the httpd instance has been up for a while and is probably somewhat busy.
Based on what I can currently see, the trap appears to be in this section of code:
zend_alloc.c:1244
#if ZEND_MM_STAT
do {
size_t size = heap->size + bin_data_size[bin_num];
size_t peak = MAX(heap->peak, size);
heap->size = size;
heap->peak = peak;
} while (0);
#endif
Attempting to annotate the disassembly, I get:
621b5a78-0045_21-HTTPD-exceptq.txt:36
1DAF7046 ADD EBX, EBX (01db)
1DAF7048 ADD EBX, EBX (01db)
1DAF704A ADD EDX, EBX (01da) ; ->
bin_num
1DAF704C MOV ECX, [EDX*4+0x1daf86c0] (8b0c95 c086af1d) ;
bin_data_size[bin_num]
1DAF7053 >ADD ECX, [EAX+0x4] (0348 04) ;
heap->size
1DAF7056 MOV EBX, [EAX+0x8] (8b58 08) ;
heap->peak
1DAF7059 CMP EBX, ECX (39cb) ; size
1DAF705B JAE 0x1daf705f (73 02)
which says the pointer to heap is NULL.
========================================================================
These are the "normal"
#define XCPT_ASYNC_PROCESS_TERMINATE 0xC0010002
which you might understand if you read the docs. You have seen them on and off for years. The exception is always reported to every other thread when some thread dies. You are only going to see them in popuplog if the exception causes a kernel API to be terminated early, which is what
happened in this case. In this case the thread was waiting on a semaphore, so the kernel terminated the wait and reported the exception to the thread.
>03-03-2022 21:15:34 SYS3170 PID 1f8a TID 0001 Slot 0085
>D:\APACHE\BIN\HTTPD.EXE
>8ef4458b
>04538bc3
>P1=4489138b P2=e8b80c24 P3=891ec898 P4=8910245c
>EAX=02af0004 EBX=02af0004 ECX=02af0000 EDX=ffffffff
>ESI=1ec0871e EDI=ffffffff
>DS=0053 DSACC=d0f3 DSLIM=5fffffff
>ES=0053 ESACC=d0f3 ESLIM=5fffffff
>FS=150b FSACC=00f3 FSLIM=00000030
>GS=0000 GSACC=**** GSLIM=********
>CS:EIP=005b:1ee00a34 CSACC=d0df CSLIM=5fffffff
>SS:ESP=0053:007ff1a8 SSACC=d0f3 SSLIM=5fffffff
>EBP=007ff1f4 FLG=00010216
I suspect there is an exceptq report associated with this popuplog entry.
========================================================================
I took a look at the code in the debugger. My basic conclusion is that something has to go very wrong for this particular exception to occur.
As I mentioned, looking at 621b5a78-0045_21-HTTPD-exceptq.txt, this
Trap -> 1DAF7053 PHP7 0001:009A7053 zend_alloc.c#1252
@_emalloc@4 + 3F 0001:009A7014 (U:\dev\php-7.4.28\Zend\zend_alloc.c)
occurs because
1DAF7053 >ADD ECX, [EAX+0x4] (0348 04)
and
EAX : 00000000 EBX : 00000009 ECX : 00000010 EDX : 00000001
Based on what I can currently see, the trap appears to be in this section of code:
zend_alloc.c:1244
#if ZEND_MM_STAT
do {
size_t size = heap->size + bin_data_size[bin_num];
size_t peak = MAX(heap->peak, size);
heap->size = size;
heap->peak = peak;
} while (0);
#endif
Attempting to annotate the disassembly, I get:
621b5a78-0045_21-HTTPD-exceptq.txt:36
1DAF7046 ADD EBX, EBX (01db)
1DAF7048 ADD EBX, EBX (01db)
1DAF704A ADD EDX, EBX (01da) ; ->
bin_num
1DAF704C MOV ECX, [EDX*4+0x1daf86c0] (8b0c95 c086af1d) ;
bin_data_size[bin_num]
1DAF7053 >ADD ECX, [EAX+0x4] (0348 04) ;
heap->size
1DAF7056 MOV EBX, [EAX+0x8] (8b58 08) ;
heap->peak
1DAF7059 CMP EBX, ECX (39cb) ; size
1DAF705B JAE 0x1daf705f (73 02)
which says the pointer to heap is NULL.
Here's where things get interesting. When @_emalloc4 is called the first
thing it does is call _os2_get_tsrm_ls_cache to get the cache pointer into
EAX. Then it gets the offset to the heap within the cache (0x970) adds
this to EAX to point EAX at the. Then it looks at the requested size to
determine which allocation routine to use. This does not require access
the heap via EAX. Since the requested size is small the inline version of
zend_mm_alloc_small is used. As soon as zend_mm_alloc_small attempts to
access the heap via EAX, it traps.
At this point, I am assuming this is the result of an out of resources problem.
The question is how did the heap initialization fail without being reported in the logs by zend_mm_init?
We should have seen this in the logs if ZEND_MM_ERROR was defined
Zend\zend_alloc.c:1852
fprintf(stderr, "\nCan't initialize heap: [%d] %s\n", errno,
strerror(errno));
but what I seen in the debugger implies it is not.
FTR, the pointer is stored in cache by:
Zend\zend_alloc.c:2772
alloc_globals->mm_heap = zend_mm_init();
========================================================================
Yet more comments on this trap.
The php code seems to assume that zend_mm_init will fail so infrequently that dumping an error message to stderr is sufficient. This is probably true for a 64-bit system. It's pretty hard to get to the point where zend_mm_chunk_alloc_int could actually fail just be running out of address space.
This is not so true for our 32-bit platform. Perhaps we should find a way to cleanly terminate the failing thread.
Perhaps we can add code after
Zend\zend.c:864
start_memory_manager();
to check if the heap pointer is NULL and if this occurs log the error and terminate the thread?
========================================================================
More of my thinking from this morning. The recommended current solution is to modify php_apache_server_startup terminate process and fail with HTTP_INSUFFICIENT_STORAGE
when the mm_heap_init fails. This should prevent the trap. |
|
(0003957)
psmedley
2022-03-05 01:12
|
FWIW: latest diff is https://smedley.id.au/tmp/php-7.4.28.diff |
|
(0003972)
emax
2022-03-11 15:10
|
is there anything i can do about this ticket?
logs? search other traps etc..? |
|
(0003973)
Steven Levine
2022-03-11 17:05
|
We do not need more random exceptq reports for the same exception. What may be more useful is a copy the log files from 5 seconds before the exception and for 1 second after the exception along with the corresponding exceptq report. The exceptq report must indicate:
Filename: C:\USR\LIB\PHP7.DLL (02/26/2022 10:10:19 25,273,142)
Address: 005B:1DAF7053 (0001:009A7053)
Cause: Attempted to read from 00000004
(not a valid address)
It's OK for the 1DAF in 005B:1DAF7053 to vary, but the 0001:009A7053 must match exactly.
We also need to know more about the typical load on your system. You need to learn to use Theseus Working Set feature for this. It's the System->Working Set item on the main menu. The online help is very good, so the vast majority of user have no problems learning to capture the data without any assistance. We will help you interpret the data when you have captured some. From the "Working Set for the System" window, use Functions->Working Set Start to start the data capture. Capture about 5 minutes of data and stop the data capture. Use the Output->Save as menu item to save the data to a file and upload it here for analysis.
|
|
(0003974)
Steven Levine
2022-03-11 17:26
(Last edited: 2022-03-11 17:30) |
Here's my current plan to avoid these kinds of exceptions.
The modphp startup hook is defined in
php_ap2_register_hook
When triggered by httdp, the hook runs as
php_apache_server_startup
sapi_startup
ts_allocate_fast_id
alloc_globals_ctor
zend_mm_init
When zend_mm_init fails, we will trap eventually.
To avoid the exception, we need to detect the init failure and fail the startup request.
Any functions in the call path that currently returns void will need to be modified to return status
This will allow
sapi_apache2.c:477
php_tsrm_startup();
to detect the failure and return return one of:
#define HTTP_INSUFFICIENT_STORAGE 507
#define HTTP_INTERNAL_SERVER_ERROR 500
#define DECLINED -1 /**< Module declines to handle */
when zend_mm_init fails. HTTP_INSUFFICIENT_STORAGE is probably the best choice.
We may be able to use the existing apr pool to generate a decent log message.
This should allow the individual request to fail without trapping the httpd instance.
|
|
(0003975)
Steven Levine
2022-03-11 17:34
|
An additional thought in addition to the above is to sleep and retry the mm_init several times before failing under the assumption that the resource issue is temporary. |
|
(0003980)
Steven Levine
2022-03-11 23:27
|
Here's a modified plan to avoid exceptions during php startup.
The modphp startup hook is defined in
php_ap2_register_hook
as
php_apache_server_startup
When triggered by httpd, the hook runs as
php_apache_server_startup
php_tsrm_startup
tsrm_startup
and
php_apache_server_startup
sapi_startup void return
ts_allocate_fast_id
alloc_globals_ctor void return
zend_mm_init
When zend_mm_init fails, we will trap eventually if the failure is ignored.
To avoid the exceptions, we need to detect errors and fail the startup request.
This is easy for the call to php_tsrm_startup
It will take a bit more work for sapi_startup. The functions in the call path that currently returns void will need to be modified to return status
There are several return options:
#define HTTP_INSUFFICIENT_STORAGE 507
#define HTTP_INTERNAL_SERVER_ERROR 500
#define DECLINED -1 /**< Module declines to handle */
HTTP_INSUFFICIENT_STORAGE is probably the best choice.
This should allow individual requests to fail without trapping the httpd instance.
This along with an mm_init retry loop should improve stability. |
|
(0003991)
Steven Levine
2022-03-20 07:07
(Last edited: 2022-03-20 07:08) |
The following patches should avoid, some if not all, of the traps that php 7.4.28 experiences when It unexpectedly runs out of resources. The indent is to fail the request with HTTP_INSUFFICIENT_STORAGE.
|
|
(0003992)
psmedley
2022-03-20 07:42
(Last edited: 2022-03-20 07:45) |
Unfortunately I'm getting a build break in tsrm.c
See attached.
The missing definition for HTTP_INSUFFICIENT_STORAGE is easy, as is the missing ( at line 458 - but I'm not clear what value OK should have
|
|
(0003993)
Steven Levine
2022-03-20 17:44
|
The undefined values come from httpd.h. Worse yet, there was a typo in an if statement. It really works so much better if I actually remember to
gcc %CFLAGS -c %FN |& tee clip:
for every file before delivering the patch set. The replacement .diff should apply cleanly after a git co -- TSRM.c to revert the results of the bad patch.
Sorry. |
|
(0003994)
Steven Levine
2022-03-20 19:08
|
One more patch for the list. I was really distracted, I guess. |
|
(0003995)
psmedley
2022-03-20 20:55
|
https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220321.zip has these patches. Other than making sure that a test.php works, not tested as it's a working day here. |
|
(0003996)
Steven Levine
2022-03-21 00:48
|
While testing I located another possible code path for a startup allocation faiilure. I also added a few more ifdef __OS2__'s to make our mods easier to spot. The zend_signal patches are new. The rest are replacements for existing patches. |
|
(0003997)
emax
2022-03-21 08:35
|
hi all,
patch: https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220321.zip
installed yesterday 20/3/2022 at 22:03 (10:03 pm) |
|
(0003998)
psmedley
2022-03-22 06:01
|
https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220322.zip contains the additional patches from https://mantis.smedley.id.au/view.php?id=745#c3996 |
|
(0003999)
emax
2022-03-22 07:12
|
thanks
latest patch installed |
|
(0004000)
emax
2022-03-22 20:58
|
as requested
thanks for the support |
|
(0004032)
Steven Levine
2022-04-05 00:36
|
A bit of quality time with the debugger tells me that at least two of the latest patches did not apply and I suspect I know why. The files that did not get patched as expected are:
TSRM.c.
zend_alloc.c
The reason is occurred is that when we upload a file to a ticket, if the the upload duplicates an existing
file, Mantis silently renames the file. As a result, ticket and 745 and 748 contain:
sapi_apache2.c.diff
sapi_apache2-2.c.diff
TSRM.c.diff
TSRM.c-2.diff
TSRM.c-3.diff
zend_alloc.c.diff
zend_alloc-2.c.diff
and so on. This is good for historical reference, but not so good when it comes to avoiding applying
a stale diff, which is what I suspect happened.
My procedure to avoid inadvertently applying stale patches is to keep the current patch set in a separate directory. When I download an updated patch, I am supposed to notice the filename mismatch and overwrite the stale patch file with the new file. I may keep local copies of the stale patch files, but they
will always be in some other directory. It's probably not a perfect solution, but it works for me.
For reference, the current accumulated patch set for tickets 745 and 748 is:
03-20-22 17:41 1,364 0 SAPI.c.diff
03-20-22 17:41 489 0 SAPI.h.diff
03-20-22 17:41 1,893 0 sapi_apache2.c.diff
03-29-22 10:53 4,083 0 TSRM.c.diff
03-29-22 10:53 1,987 0 zend_alloc.c.diff
03-20-22 17:41 1,020 0 zend_signal.c.diff
03-20-22 17:41 452 0 zend_signal.h.diff
03-29-22 10:53 1,014 0 zend_virtual_cwd.c.diff
Your local time stamps will differ, but the file sizes should all match. |
|
(0004033)
psmedley
2022-04-05 02:05
|
Hi Steven, apologies for this. I'm planning to add the 7.4.28 sources to fit to make things easier to manage, and I'll add all three diffs in a branch for simplicity. |
|
(0004036)
psmedley
2022-04-05 09:15
|
git repo created. https://github.com/psmedley/php-7-os2/tree/ticket-745-748 has the current diffs. Configuring now.... |
|
(0004040)
psmedley
2022-04-05 21:28
|
Updated build based on the the git branch in 004036. https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220406.zip |
|
(0004044)
emax
2022-04-06 07:21
|
installed, thanks
it has no .map file, is this ok? |
|
(0004045)
psmedley
2022-04-06 07:50
|
It's a debug build, so it doesn't need a mapfile |
|
(0004047)
Steven Levine
2022-04-06 08:17
|
It's getting late here. I will fork the branch and verify that we are in sync on the patches. Since we are using github, should I plan on using pull requests going forward? It won't kill me to learn to use them effectively. |
|
(0004048)
emax
2022-04-06 08:22
|
first eQ dump and apache error log |
|
(0004049)
emax
2022-04-06 08:25
|
and the other 2 eQ dumps (as from the error log, sorry)
sorry for the fragmented post |
|
(0004050)
psmedley
2022-04-06 09:20
|
@Steven - part of my motivation for creating the github was to make sharing patches more efficient. PR's would likely be the best method to share patches. I'm not sure (yet) how best to apply patches if they end up releasing a 7.4.29 but we'll cross that bridge when we come to it. |
|
(0004051)
Steven Levine
2022-04-06 16:20
|
@emax, we appear to have moved the exception. Whether or not this is still the same problem, it is TBD.
@paul, I'm not 100% sure we have our patches in sync yet. I'll know more once I get in sync with the new repo.
@paul, applying the patches to a 7.4.29 or 8.1.x, when the time comes, will not be a problem. git and github make the process reasonably easy. At worst, we might have to resolve a few conflicts. We can discuss the process elsewhere when the time come. If you haven't worked with pull requests before, a simple example is https://github.com/bitwiseworks/libc/pull/121. Sylvan created the commit to be pulled on a branch, but the pull request can come from any forked repo because they are sufficiently related.
@paul, I am thinking we should mark #748 a duplicate of this ticket and mark #748 closed. The #748 exceptions are really the same out of memory issue failing in different ways. What do you think? |
|
(0004052)
psmedley
2022-04-07 08:56
|
@steven a couple of patches didn't apply cleanly, but I'm pretty confident I manually applied in the right spot. I have worked with PRs before, as I've contributed to Openhab previously.
I agree re: 748 so I've closed it and marked as a duplicate of 745 :) |
|
(0004099)
Steven Levine
2022-04-17 06:56
(Last edited: 2022-04-20 00:32) |
@paul, based on the content of branch-745-748, it appears that all my patches made it into your builds, there is not need for a pull request at this time.
I did notice a few spurious whitespace changes, but none were in the code that I patched. They will not matter unless we are unlucky and an upstream change affects these lines. This is not very likely given that 7.4 is only getting security updates.
git diff php-7.4.27..php-7.4.28 . tells me that nothing that will affect us changed.
Now that we know we are in sync, let's see how php dies when running with https://smedley.id.au/tmp/php-7.4.28-dll-debug-20220415.zip installed.
|
|
(0004140)
Steven Levine
2022-04-27 01:57
(Last edited: 2022-04-27 01:58) |
@massimo, do you have any occurrences of
[Fri Mar 25 12:21:57.470000 2022] [cgi:error] [pid 100:tid 6] (8)Invalid executable file format: [client 194.165.16.27:37016] couldn't create child process: 8: docsearch.cmd
in your apache error logs?
|
|
(0004141)
emax
2022-04-27 07:36
|
no, i don't use CGI, even the module is disabled |
|
(0004142)
Steven Levine
2022-04-27 17:46
|
Since updating to php-7.4.28-dll-debug-20220426.zip are you still getting error log entries list those in
https://mantis.smedley.id.au/file_download.php?file_id=653&type=bug
which you attached to
https://mantis.smedley.id.au/view.php?id=745#c4000
If so, please upload a few of the unique exceptq reports and the last 15 minutes of the error log. |
|
(0004143)
Steven Levine
2022-04-27 18:27
|
@massimo, I think I confused you with too much information. What I intended to ask was if you had any occurrences of the
couldn't create child process: 8
error, not just for CGI operations. Httpd creates processes for a number of reasons and potentially any of these process create attempts could fail and this error indicates that the system is out of resources.
BTW, my most recent copy of your httpd.conf loads modcgi. Please upload a current reference copy of your httpd.conf. |
|
(0004144)
emax
2022-04-27 18:38
|
i've a huge number of these:
mmap() failed: [12] Not enough memory
Can't initialize heap: [12] Not enough memory
Killed by SIGSEGV
pid=0x0f49 ppid=0x0f41 tid=0x0021 slot=0x00e7 pri=0x0200 mc=0x0001 ps=0x0010
D:\APACHE\BIN\HTTPD.EXE
cs:eip=20337918:00000006 ss:esp=0001:000020c0 ebp=02f80053
ds=0000 es=0000 fs=0000 gs=0000 efl=02f8f948
eax=02f8fa14 ebx=1ffc9d7c ecx=02f8fa28 edx=02f8fa4c edi=00000000 esi=02f8ffd4
Creating 0F49_21.TRP
Moved 0f49_21.TRP to C:\var\log\app\62694798-0f49_21-
mmap() failed: [12] Not enough memory
the 1st dump in the log is in \var\log\app dir
while the 2nd dump in the log is \apache dir |
|
(0004145)
emax
2022-04-27 18:50
|
@Steven (4143)
i've searched all the logs
i don't have *create child process* in any kind of apache or php log |
|
(0004146)
Steven Levine
2022-04-28 03:54
|
@paul. Please check https://mantis.smedley.id.au/file_download.php?file_id=679&type=bug against your sources. Using the ticket-745-748 branch from your repo, the line numbers reported in the exceptq report do not match up the sources as I would expect them too. I'll recheck in the morning with the debugger. It's possible that this is just a side effect of the code optimizer. |
|
(0004147)
psmedley
2022-04-28 09:47
|
EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 1DAFDA80 PHP7 0001:009ADA80 zend_alloc.c#2537 @_emalloc@4 + 17 0001:009ADA69 (U:\dev\php-7-os2\Zend\zend_alloc.c)
This one looks reasonable
02F8FB84 1DB5D15D PHP7 0001:00A0D15D zend_virtual_cwd.c#151 _virtual_cwd_main_cwd_init - F5F 0001:00A0E0BC (U:\dev\php-7-os2\Zend\zend_virtual_cwd.c)
This is way off- 0000151 is _cwd_globals_ctor - virtual_cwd_main_cwd_init is at 0000181
02F8FBA4 1DAA045F PHP7 0001:0095045F TSRM.c#445 _tsrm_startup - 49 0001:009504A8 (U:\dev\php-7-os2\TSRM\TSRM.c)
This one is also out.... #445 is 80% through allocate_new_resource; tsrm_startup is at 0000147
02F8FBE4 1DAA0A90 PHP7 0001:00950A90 TSRM.c#504 _ts_resource_ex + 7B 0001:00950A15 (U:\dev\php-7-os2\TSRM\TSRM.c)
This one might be OK....0000504 is actually in ts_resource_ex |
|
(0004148)
Steven Levine
2022-04-29 02:51
|
@paul. I see what's going on. Somehow, the sources you built with are not all from the ticket-745-748 branch. Given:
>git branch
main
* ticket-745-748
If I do:
git co main -- Zend/zend_alloc.c
git co main -- TSRM/TSRM.c
the debugger is happy to show source code that matches up with the executable code.
From the debugger, I can see that the patches associated with these files on the ticket-745-748 branch not there, which explains why is still trapping when the mm_heap init fails.
At first I thought you might have built from the main branch, but I think it's something else you did. The code for xp_socket.c is as it should be for the ticket-745-748 branch. |
|
(0004149)
psmedley
2022-04-29 03:07
(Last edited: 2022-04-29 03:44) |
hmm that's embarassing :( full rebuild coming real soon now.
Edit: https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220429.zip
Part of the issue is likely that 'make clean' wasn't terribly effective as it was removing *.o & *.a; not *.obj and *.lib
|
|
(0004150)
emax
2022-04-29 05:32
|
hi,
should i install this build or wait for the "full rebuild"?
thanks |
|
(0004151)
psmedley
2022-04-29 05:33
|
the build above *is* the full rebuild |
|
(0004152)
emax
2022-04-29 12:22
|
installed now
thanks a lot
i will let you know how it works
but since the first minutes i don't see errors in apache error log and this is good |
|
(0004153)
emax
2022-04-29 14:50
|
apache seems much more stable than before in 2,5 hours of uptime just one trap
apache error log:
[Fri Apr 29 16:03:41.529000 2022] [negotiation:error] [pid 5393:tid 6] [client 66.249.76.83:58018] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/xyz/index.html (None could be negotiated).
Killed by SIGSEGV
pid=0x1511 ppid=0x1115 tid=0x0001 slot=0x0071 pri=0x0200 mc=0x0001 ps=0x0010
D:\APACHE\BIN\HTTPD.EXE
cs:eip=3fc94040:0000003a ss:esp=7b20:20030150 ebp=007f0053
ds=0000 es=0000 fs=0014 gs=0000 efl=203384d8
eax=007ff968 ebx=1ffc9d7c ecx=007ff97c edx=007ff9a0 edi=007ff860 esi=007fff7c
Creating 1511_01.TRP
Moved 1511_01.TRP to C:\var\log\app\626c0faa-1511_01-HTTPD-exceptq.txt
[Fri Apr 29 16:24:53.971000 2022] [authz_core:error] [pid 5566:tid 26] [client 39.107.108.36:59304] AH01630: client denied by server configuration: D:/apache24 |
|
(0004154)
Steven Levine
2022-04-29 16:57
|
@paul. It appears we are getting closer, but are not quite there yet. the xp_socket.c patches are now in the executable, but the TSRM/TSRM.c and the Zend/zend_alloc.c patches are not.
Rather than a make clean, try deleting just the associated .obj and .lo files and check that make recreates them correctly. As a sanity check verify that that the .obj and .lo timestamps are newer than the source files.
Poking about it looks like we need to patch build\Makefile.global which defines the clean action to make the .obj files go away. |
|
(0004155)
psmedley
2022-04-29 21:56
(Last edited: 2022-04-29 22:13) |
make clean is fixed in https://github.com/psmedley/php-7-os2/commit/8b3163adabe6478b415f3f5b7c6554cfc3013771
I mistakenly build from main, not the branch
New build at https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220430.zip
|
|
(0004156)
Steven Levine
2022-04-30 01:47
|
@paul. Looks good. All the patches seems to be in place. Let's see how stable this build is for massimo.
BTW, I noticed you merged the ticket-745-748 branch to main. Do this mean we can make the branch go away and this you will be building from main going forward? If so, that's fine with me.
I took a quick look at https://mantis.smedley.id.au/file_download.php?file_id=682&type=bug. It's not new. Massimo uploaded 2 previous occurrences. I suspect the trap is the result of a connection that failed early enough so that the statistics buffers were not fully initialized. |
|
(0004157)
psmedley
2022-04-30 05:22
|
@Steven -I figured the patches in the branch were doing no harm, so they might as well be in main. Yes I've deleted this branch from my repo. If we're doing any experimental changes I may build them from a branch until their proved to be valid, but for now I'll build from main. |
|
(0004158)
Steven Levine
2022-04-30 13:57
|
@Paul. This is sorta the preferred way of working with git. Most branches have a short life span. Without the build issues, the ticket-745-748 branch would have been retired many days ago.
It will be interesting to see how good a job the patches do at helping Massimo avoid reboots. |
|
(0004159)
emax
2022-04-30 21:01
|
latest build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220430.zip
give:
[Sat Apr 30 23:00:29.186000 2022] [:emerg] [pid 6869:tid 1] AH00020: Configuration Failed, exiting
at apache startup and exit |
|
(0004160)
psmedley
2022-04-30 21:38
|
@Massimo I can't reproduce this here. command line usage and usage with apache works for me. |
|
(0004161)
emax
2022-04-30 21:41
|
apache do not give any details just that configuation failed |
|
(0004162)
psmedley
2022-04-30 21:43
|
anything in PHP error log? |
|
(0004163)
emax
2022-04-30 22:24
|
no.. |
|
(0004164)
Steven Levine
2022-05-01 05:50
|
If I am reading the code correctly, AH00020: Configuration Failed means one of the post config hooks failed. These run to initialize loaded modules among other tasks.
There appears to be a problem with the new modphp.dll. Backleveling modphp.dll avoids the AH00020 failure here. Does this work for you?
|
|
(0004165)
Steven Levine
2022-05-01 06:05
|
The patches in
sapi\apache2handler\sapi_apache2.c:459
php_apache_server_startup(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp, server_rec *s)
are not quite right.
We have:
sapi\apache2handler\sapi_apache2.c:484
// 2022-03-14 SHL Get out if startup failed
err = php_tsrm_startup();
if (err != OK)
return err;
which is backwards. php_tsrm_startup returns a boolean, not an error code. I need to fix the compare figure out what error code to return |
|
(0004166)
psmedley
2022-05-01 08:50
|
New build with Steven's fix is at https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220501.zip |
|
(0004167)
emax
2022-05-01 09:40
|
same with this new build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220501.zip
[Sun May 01 11:36:16.031000 2022] [:emerg] [pid 1714:tid 1] AH00020: Configuration Failed, exiting
if i put *only* modphp7.dll from this build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220429.zip
apache start and work |
|
(0004168)
psmedley
2022-05-01 10:03
|
@Steven - doesn't tsrm_storage return 1 for success and 0 for failure?
The way I read the code - we're calling 'return HTTP_INSUFFICIENT_STORAGE;' when ok= 1 which seems wrong |
|
(0004169)
Steven Levine
2022-05-01 19:57
|
The return codes are a mix of booleans, numeric error codes and id codes and some of return code checks I added are still wrong. Another pull request is in our future. |
|
(0004170)
psmedley
2022-05-02 21:24
|
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220503.zip has the fixes from https://github.com/psmedley/php-7-os2/commit/9e64877c522b47de3858b0b13b34fb3ee8268685 |
|
(0004171)
Steven Levine
2022-05-03 07:15
|
Grumble. One more fix to do. If I work around it in the debugger, I get a clean startup. I'll submit a pull request in the morning. |
|
(0004172)
psmedley
2022-05-03 07:46
|
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220503b.zip includes the fixes from https://github.com/psmedley/php-7-os2/commit/bfc2515da67b3bde88fcb7a620198b6b87ab9e7a |
|
(0004173)
emax
2022-05-03 12:32
|
ok guys, this build
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220503b.zip
has installed correctly and apache regularly start |
|
(0004174)
psmedley
2022-05-03 21:25
|
@Max - I assume you kept running the updated php7.dll from https://mantis.smedley.id.au/view.php?id=745#c4167 - how has stability been over the last couple of days. |
|
(0004175)
emax
2022-05-04 07:52
|
@paul
hi, i'm using all the dlls (php7, modphp and all modules) from https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220503b.zip build
this build is more stable anyway it seems to me that WP websites renders a bit slower, but this could be just a sensation
in the last days i'had just one reboot (for an http unkillable child) and this is very very good
but i have just one (strange/incomplete) eQ dump in \apache dir, a numver of entries in popuplog.os2
and 60 eQ dumps in \var\log\app since yesterday morning at 11,40 (when i upgraded to 20220503b)
in the apache error log i still see a number of mmap() failed: [12] Not enough memory
or some
Can't initialize heap: [12] Not enough memory - retry 1 U:/dev/php-7-os2/Zend/zend_alloc.c(1853)
Can't initialize heap: [12] Not enough memory - retry 2 U:/d
mmap() failed: [12] Not enou
(last 2 are strange since they are uncomplete)
in attachment you can find some eQ dump about php7.dll |
|
(0004176)
emax
2022-05-04 07:55
|
i've talked too early..
sometimes this build show this on WP websites
you reload the page and the website show correctly
but this is no good :( |
|
(0004177)
emax
2022-05-04 08:01
|
these are error log and eQ dump that generated that http 500 webpage |
|
(0004178)
Steven Levine
2022-05-04 15:02
|
Is 163C_18.TRP really only 569 bytes or is this a bad upload?
last_part_apache_error_log reports:
Moved 0688_01.TRP to C:\var\log\app\62724d7c-0688_01-HTTPD-exceptq.txt
Is there a reason you did not upload a copy of 62724d7c-0688_01-HTTPD-exceptq.txt?
I know it's hard for you to understand this, but it will always be important to upload related files when the relationship is obvious.
I will see what we can do to avoid these exceptions.
As we have said before, the current goal is to avoid as many of the exceptions as possible. Once we are done with this we will focus on tuning your configuration to avoid as many out of resource issues as possible.
@massimo. Did you ever read and understand my Wed, 16 Mar 2022 message to the apache/2 list with subject
"Thoughts on OS/2 httpd mpmt tuning?"
If not, I recommend you spend some time to do this. It's pretty much required to properly tune your httpd/php configuration. |
|
(0004179)
emax
2022-05-04 16:26
|
i don't know why but build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220501.zip + *only* modphp7.dll from this build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220429.zip
was much more stable than the latest https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220503b.zip
i already had 2 reboots today
Is there a reason you did not upload a copy of 62724d7c-0688_01-HTTPD-exceptq.txt?
no, just a mistake, i've a lot of eQ dumps so i took the wrong one, you have in attachment the right one now
about email of 16 Mar 2022 i don't have any kind of email with that subject here, i never received it
neither an answer to that email in the mailing list |
|
(0004180)
Steven Levine
2022-05-04 18:34
|
I can only guess why you did not receive the email. Here's a link to the message in the google groups archive
https://groups.google.com/g/apache2/c/L81HtD7aVOM
I have to guess that you are not aware, all messages to the list are archived to
https://groups.google.com/g/apache2
The is exactly the same as how goggle handles every other google group.
As to your comments about relative stability, quasarbbs seems to get overloaded more often than other systems running our httpd/php ports. All we can do is address the issues on at a time.
It's possible some of the slowness you noticed is a side effect of the #751 fix. I submitted a pull request with an optimized patch. We will see is this change helps.
BTW, did you not realize that every one of the exceptq reports you uploaded for 0000745:0004175 are duplicates? If not you will save everyone time by spending a bit of time learning to better recognize duplicates.
62724d7c-0688_01-HTTPD-exceptq.txt is a different. I will review it and see what we can do to avoid it.
|
|
(0004181)
emax
2022-05-04 18:49
|
i've read now the post, sorry, but i don't believe it's quite useful for a configuration like my one
StartServers 5
MinSpareThreads 28
MaxSpareThreads 50
MaxRequestsPerChild 115
if i reduce numbers i get poor performances |
|
(0004182)
psmedley
2022-05-05 09:17
|
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220505.zip includes the fixes from https://github.com/psmedley/php-7-os2/commit/85e5c9165eb5081f949cf62247460e05fa28d51b |
|
(0004183)
emax
2022-05-05 09:53
|
ok, installed https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220505.zip
apache start and work correctly
i will update you |
|
(0004184)
emax
2022-05-05 18:45
|
2 reboots in few hours due to apache unkillable childs
e.g.
1658 139.988M 370.988M 35837 94973 HTTPX
i'm sorry for the zipped attachment but Mantis do not accept files >3MB
i feel very sorry if i have uploaded something not useful, but it's quite difficult to me to understand wich eQ trap is good or not |
|
(0004185)
Steven Levine
2022-05-06 03:36
|
For the vast majority of exceptq reports it's really almost trivially easy to tell if the report is a duplicate of some other report. You are the only one I recall in recent memory that continues to have trouble with this.
In 6273f59a-0043_21-HTTPD-exceptq.txt the trap is reported as:
Trap -> 1DAFC603 PHP7 0001:009AC603 zend_alloc.c#2485 @_emalloc_256@0 + 14 0001:009AC5EF (U:\dev\php-7-os2\Zend\zend_alloc.c)
If you have another exceptq report with the same file and line number (i.e. zend_alloc.c#2485), it's duplicate. As a secondary confirmation, you can compare the disassembled code. In this case, it's
1DAFC5F2 SUB ESP, 0x8 (83ec 08)
1DAFC5F5 CALL 0x1daa0ece (e8 d448faff)
1DAFC5FA MOV EDX, [0x1859ce68] (8b15 68ce5918)
1DAFC600 MOV EAX, [EDX+EAX] (8b0402)
1DAFC603 >MOV EAX, [EAX] (8b00)
1DAFC605 TEST EAX, EAX (85c0)
1DAFC607 JNZ 0x1dafc64e (75 45)
1DAFC609 CALL 0x1daa0ece (e8 c048faff)
If the disassembly is the same other report than the memory addresses, it's the same trap.
The situation is a bit more complicated for 627416ca-05ab_01-HTTPD-exceptq.txt where the exception is caught by libc/libcx. In this case, the
Trap -> 1ECC367D LIBCN0 0001:000F367D b_panic.c#537 ___libc_Back_panicV + 1C30 0001:000F1A4D (b_panic.obj)
line is obviously not useful because it always the same file line number. Normally you would scan the Call Stack and find the first caller that is not in libc/libcx. If one exists, you would check the file and line number of this caller and if it matches some other exceptq report, the report is almost surely a duplicate.
In this case the Call Stack terminated without such a caller. Looking at Labels on the Stack, it appears that the exception originated at:
007FFD48 1EAA0100 HTTPD 0001:00000100 between _ap_get_server_built + 80 and _main - 1492 (in ldconv_buildmark_o_1e2061ca2b9413bd08.obj and main.o)
but this is a quick guess on my part. You would get bonus points if you recognized this as a duplicate of some other exceptq report.
627424cd-088d_01-HTTPD-exceptq.txt is similar to the first report in that the exception is not in libc/libcx. It's at
Trap -> 1EB24A3D HTTPD 0001:00084A3D between _apr_dbm_get_usednames_ex + 34 and _apr_dbm_get_usednames - 23 (both in apr_dbm.c)
so it's trivially easy to check if this is a duplicate of some other report. Since this is a retail build, you don't have file and line numbers, but you do have function names and offsets (i.e. _apr_dbm_get_usednames_ex + 34). If this matches some other exceptq report, this is a duplicate.
FWIW, unless you have a very good reason, you should not be running retail builds when there is a debug build available. I will not put much time into trying to debug an trap in a retail build.
All three reports are probably the result of running out of system resources.
The exception at
Trap -> 1DAFC603 PHP7 0001:009AC603 zend_alloc.c#2485 @_emalloc_256@0 + 14 0001:009AC5EF (U:\dev\php-7-os2\Zend\zend_alloc.c)
we know how to avoid. We have seen this trap in similar code. I will prepare a patch for Paul.
The other types of exceptions will continue to occur until you tune your system to better avoid running out of resources.
067A_18.TRP is interesting. At first glance, it appears that our patches caught an out of memory condition that would have trapped in the past. That bad news is it appears that error reporting code tries to allocate memory to log the error and since there is no memory available things go circular until you run out of stack.
I thought this might happen, but want to see it occur before trying to implement a patch that deal with it. The way this is typically handled is that on startup the code allocates a safety buffer. When system runs out of memory, the safety buffer is freed and hopefully this frees up enough heap space to so that the error reporting code can finish and exit. We shall see. |
|
(0004186)
psmedley
2022-05-06 09:00
|
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220506.zip includes https://github.com/psmedley/php-7-os2/commit/707408bedad4f96afa578566733eae72ea4072ee and also openssl 1.1.1o
Note: Steven's patch should help performance, but neither of these should make any difference to the Traps reported in https://mantis.smedley.id.au/view.php?id=745#c4184 |
|
(0004187)
emax
2022-05-06 16:03
|
installed https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220506.zip
apache starts and work ok
thanks |
|
(0004191)
Steven Levine
2022-05-06 17:38
|
Regarding the theseus getram report:
Pid Private Shared Private Shared Task Names
1658 139.988M 370.988M 35837 94973 HTTPX
The shared memory usage does appear excessive. However, it's not relevant to this ticket. It you want to work on figuring out what is causing the excessive usage, open a httpd ticket. If we already have one for this issues, please remind me what the ticket number is. |
|
(0004196)
emax
2022-05-07 08:22
|
with build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220506.zip
i've a lot of issues trying to entering word press panels
i get a lot of http error 500 |
|
(0004200)
Steven Levine
2022-05-07 14:20
|
My bad. Sloppy coding on my part. Wait for next build. |
|
(0004201)
psmedley
2022-05-07 21:59
|
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220508.zip has Steven's latest patch. |
|
(0004205)
emax
2022-05-08 11:53
|
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220508.zip build installed
but had to remove it allmost after some minutes all php websites give "ERR_EMPTY_RESPONSE"
and this is a serious issue since build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220506.zip is very very very unstable
about 5 reboots per day and a crash of apache each now and then :-( |
|
(0004206)
emax
2022-05-08 11:56
|
|
|
(0004208)
Steven Levine
2022-05-08 15:06
|
Thanks for testing. I can see what's happening in the exceptq report, but it's not yet obvious what's wrong. We will let you know when a new test build is available. |
|
(0004214)
psmedley
2022-05-09 00:07
|
https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220509.zip should help. |
|
(0004215)
emax
2022-05-09 10:08
|
Hi,
thanks, but had to revert immediately to build: https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220506.zip
this new build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220509.zip crash allmost some seconds after startup..
apache error log and eQ dumps in attachment, i'm sorry if i upload something duplicated
i've also a crash on SSL module should i upload it?
thanks |
|
(0004218)
emax
2022-05-09 19:34
|
i've a lot of this stuff in apache error log before apache crash/exit
[Mon May 09 21:29:37.999000 2022] [mpm_mpmt_os2:error] [pid 582:tid 1] (OS 105)The previous ownership of this semaphore has ended. : Sem owner died pidSemaphoreOwner = 580, tidSemaphoreOwner = 1, ulRequestCount = 1 rc = 105 at ap_mpm_child_main #0
[Mon May 09 21:29:39.177000 2022] [mpm_mpmt_os2:notice] [pid 331:tid 1] AH00201: caught SIGTERM, shutting down
is it important?
thanks |
|
(0004222)
Steven Levine
2022-05-10 02:59
|
Regarding 62790231-0c4d_03-HTTPD-exceptq.txt, I still cannot type. The others are may be related, but we will not know until the next build. |
|
(0004332)
emax
2022-05-20 21:25
|
build https://smedley.id.au/tmp/php-7.4.28-os2-debug-20220519.zip has made a huge progress in stability
here below the only 3 eQ dumps on PHP7.DLL in a day (dump in attachment and part of apache error log)
dump 0047_1
[Fri May 20 11:26:20.324000 2022] [mpm_mpmt_os2:notice] [pid 66:tid 1] AH00206: Apache/2.4.53 (OS/2) OpenSSL/1.1.1o PHP/7.4.28 configured -- resuming normal operations
Killed by SIGSEGV
pid=0x0047 ppid=0x0042 tid=0x0001 slot=0x0059 pri=0x0200 mc=0x0001 ps=0x0010
D:\APACHE\BIN\HTTPD.EXE
cs:eip=20c88a20:0000003a ss:esp=1ebdca82:20030000 ebp=007f0053
ds=0000 es=0000 fs=20030150 gs=0000 efl=00000000
eax=007ff968 ebx=1ffc9d7c ecx=007ff97c edx=007ff9a0 edi=20030000 esi=007fff7c
Creating 0047_01.TRP
Moved 0047_01.TRP to C:\var\log\app\62877e28-0047_01-HTTPD-exceptq.txt
tore&tesiDir=ASC&tesiPage=2
[Fri May 20 11:32:52.123000 2022] [negotiation:error] [pid 67:tid 9] [client 79.51.242.49:52910] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated)., referer: https://www.bing.com/
dump: 09fd_01
[Fri May 20 15:39:51.569000 2022] [negotiation:error] [pid 2380:tid 22] [client 130.35.84.153:39308] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Fri May 20 15:40:52.075000 2022] [php7:error] [pid 2380:tid 24] [client 154.54.249.205:36040] script 'D:/apache/htdocs/max/jaime-it/index.html' not found or unable to stat
[Fri May 20 15:47:48.233000 2022] [core:error] [pid 2565:tid 18] [client 35.245.82.188:1250] AH00082: an unknown filter was not added: includes
[Fri May 20 15:48:08.985000 2022] [core:error] [pid 2557:tid 27] [client 154.54.249.205:11578] AH10244: invalid URI path (/../..)
[Fri May 20 15:50:18.962000 2022] [php7:error] [pid 2566:tid 26] [client 172.104.239.240:54852] script 'D:/apache/htdocs/max/speedmarine/xmlrpc.php' not found or unable to stat
[Fri May 20 15:50:20.919000 2022] [php7:error] [pid 2566:tid 27] [client 172.104.239.240:54856] script 'D:/apache/htdocs/max/speedmarine/xmlrpc.php' not found or unable to stat
[Fri May 20 15:50:21.372000 2022] [php7:error] [pid 2557:tid 3] [client 172.104.239.240:54860] script 'D:/apache/htdocs/max/speedmarine/wp-login.php' not found or unable to stat
[Fri May 20 15:50:21.794000 2022] [php7:error] [pid 2565:tid 3] [client 172.104.239.240:54864] script 'D:/apache/htdocs/max/speedmarine/wp-login.php' not found or unable to stat
[Fri May 20 15:50:22.218000 2022] [php7:error] [pid 2567:tid 30] [client 64.227.108.223:49240] script 'D:/apache/htdocs/ecs/xmlrpc.php' not found or unable to stat
[Fri May 20 15:50:25.499000 2022] [php7:error] [pid 2567:tid 28] [client 64.227.108.223:49524] script 'D:/apache/htdocs/ecs/xmlrpc.php' not found or unable to stat
[Fri May 20 15:50:29.335000 2022] [php7:error] [pid 2566:tid 29] [client 64.227.108.223:50278] script 'D:/apache/htdocs/ecs/wp-login.php' not found or unable to stat
[Fri May 20 15:50:31.560000 2022] [php7:error] [pid 2557:tid 32] [client 64.227.108.223:50670] script 'D:/apache/htdocs/ecs/wp-login.php' not found or unable to stat
[Fri May 20 15:51:57.458000 2022] [negotiation:error] [pid 2557:tid 10] [client 157.55.39.81:1536] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Fri May 20 15:52:56.349000 2022] [negotiation:error] [pid 2557:tid 23] [client 213.26.139.50:57052] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated)., referer: https://www.google.com/
Killed by SIGSEGV
pid=0x09fd ppid=0x04df tid=0x0001 slot=0x0054 pri=0x0200 mc=0x0001 ps=0x0010
D:\APACHE\BIN\HTTPD.EXE
cs:eip=283adf20:0000003a ss:esp=1ebdca82:20030000 ebp=007f0053
ds=0000 es=0000 fs=20030150 gs=0000 efl=00000000
eax=007ff968 ebx=1ffc9d7c ecx=007ff97c edx=007ff9a0 edi=20030000 esi=007fff7c
Creating 09FD_01.TRP
Moved 09fd_01.TRP to C:\var\log\app\6287b9dd-09fd_01-HTTPD-exceptq.txt
[Fri May 20 16:00:27.369000 2022] [core:error] [pid 2652:tid 29] [client 173.231.60.196:54412] AH00082: an unknown filter was not added: includes
dump: 18cb_01
[Fri May 20 22:02:54.787000 2022] [mpm_mpmt_os2:notice] [pid 5859:tid 1] (OS 10035)Resource temporarily unavailable: apr_socket_accept
[Fri May 20 22:17:18.951000 2022] [core:error] [pid 6163:tid 5] [client 144.76.119.235:60543] AH00082: an unknown filter was not added: includes
[Fri May 20 22:17:18.970000 2022] [autoindex:error] [pid 6163:tid 5] [client 144.76.119.235:60543] AH01276: Cannot serve directory D:/apache/htdocs/max/sitep/wp-includes/: No matching DirectoryIndex (index.html,index.php,index.htm,index.shtml,index.wml,welcome.html,welcome.htm,index.php3,index.php4,index.phps,default.php,login.php) found, and server-generated directory index forbidden by Options directive
[Fri May 20 22:17:25.812000 2022] [negotiation:error] [pid 6164:tid 6] [client 144.76.119.235:57922] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated).
[Fri May 20 22:18:03.779000 2022] [php7:error] [pid 6163:tid 20] [client 101.99.90.175:41674] script 'D:/apache/htdocs/max/jaime-hw/wp-login.php' not found or unable to stat, referer: http://jaimeaymerichhollywood.com/wp-login.php
[Fri May 20 22:18:07.876000 2022] [core:error] [pid 5493:tid 1] (13)Permission denied: AH00095: failed to remove PID file D:/apache/logs/httpd.pid
[Fri May 20 22:18:07.876000 2022] [mpm_mpmt_os2:notice] [pid 5493:tid 1] AH00201: caught SIGTERM, shutting down
[Fri May 20 22:18:15.429000 2022] [mpm_mpmt_os2:notice] [pid 6339:tid 1] AH00206: Apache/2.4.53 (OS/2) OpenSSL/1.1.1o PHP/7.4.28 configured -- resuming normal operations
Killed by SIGSEGV
pid=0x18cb ppid=0x18c3 tid=0x0001 slot=0x008b pri=0x0200 mc=0x0001 ps=0x0010
D:\APACHE\BIN\HTTPD.EXE
cs:eip=27487800:0000003a ss:esp=1ebdca82:20030000 ebp=007f0053
ds=0000 es=0000 fs=20030150 gs=0000 efl=00000000
eax=007ff968 ebx=1ffc9d7c ecx=007ff97c edx=007ff9a0 edi=20030000 esi=007fff7c
Creating 18CB_01.TRP
Moved 18cb_01.TRP to C:\var\log\app\62881ada-18cb_01-HTTPD-exceptq.txt
[Fri May 20 22:49:30.249000 2022] [negotiation:error] [pid 6630:tid 4] [client 43.154.171.110:39220] AH00687: Negotiation: discovered file(s) matching request: D:/apache/htdocs/max/sitep/index.html (None could be negotiated). |
|
(0004333)
Steven Levine
2022-05-21 02:11
|
Please open a new ticket for https://mantis.smedley.id.au/view.php?id=745#c4332.
The summary should be
mysqlnd traps attempting to update statistics during connection close processing
You originally reported this issue in the now closed #748. The ticketed gather too many unrelated comments and exceptq reports and the original issue seems have gotten lost in the noise.
We are trapping at:
ext\mysqlnd\mysqlnd_connection.c:2441
MYSQLND_INC_CONN_STATISTIC(conn->stats, close_type_to_stat_map[close_type]);
I suspect this happened the connection failed before the statistics buffer get fully initialized.
|
|
(0004334)
Steven Levine
2022-05-22 02:00
(Last edited: 2022-05-22 02:10) |
The out of memory issues that were the focus of this ticket have been resolved for both 7.4.28 and 8.1.6. The remaining unrelated issues such as the trap in mysqlnd will be handled in separate tickets.
|
|
|
Notes |
(0002783)
psmedley
2014-07-20 09:20
|
I have my hands full with apr-unix right now - but will try get to it... |
|
(0002792)
psmedley
2014-08-01 09:54
|
You are running PHP 5.3? |
|
(0002793)
LewisR
2014-08-01 14:10
|
Indeed, I am, Paul (5.3.28). |
|
(0002794)
psmedley
2014-08-01 21:08
|
Not tested at all, but please try http://smedley.id.au/tmp/opcache.zip
Needs mmap.dll and pthr01.dll from rpm |
|
(0002795)
LewisR
2014-08-02 02:18
|
Not quite there yet, Paul. ;-)
[Fri Aug 01 22:04:28 2014] [info] mod_ssl/2.2.27 compiled against Server: Apache/2.2.27, Library: OpenSSL/1.0.1h
Fri Aug 1 22:04:30 2014 (537390048): Fatal Error Unable to allocate shared memory segment of 134217728 bytes: mmap: Permission denied (13)
Creating 00C3_01.TRP
The above is with php.ini configured as:
zend_extension=j:/APPS/php5/modules/opcache.dll
[opcache]
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
(The same error occurs if using the default memory consumption of 64MB.)
[j:\apps\apache2]dir j:\usr\lib\mmap.dll
11-02-11 12:14 8,574 124 mmap.dll
[j:\apps\apache2]dir j:\usr\lib\pthr01.dll
4-25-14 15:49 7,879 124 pthr01.dll
PMdll reports intermittent issues loading gcc444.dll (even after I have libpath set as I normally do to start Apache), but I don't think that's it. Both mmap.dll and pthr01.dll are in libpath. Is there any way to test mmap to make sure that it is working as expected? Both modules seem to load their dependencies (according to PMdll).
TRP file, attached. |
|
(0002796)
LewisR
2014-08-02 02:22
|
I should add the following:
The above was run on my ThinkPad t43, using the 14.105_UNI kernel(though I got similar results on my test server).
and
THANK YOU for taking the time and effort to build (and hopefully debug) this!
Cheers |
|
(0002797)
LewisR
2014-08-02 02:30
|
Possible help for the permission denied message (WAG):
http://stackoverflow.com/questions/17202741/why-does-mmap-fail-with-permission-denied-for-the-destination-file-of-a-file-c |
|
(0002798)
psmedley
2014-08-02 09:46
|
http://smedley.id.au/tmp/opcache.zip is refreshed - no idea if it works, bu apache2/php starts now
It was a limitation of our mmap implementation.
I had to add code to make it work with out mmap |
|
(0002799)
LewisR
2014-08-02 16:25
|
Thanks, Paul. Testing now (late start on the day).
Did you mean "make it work with *our* mmap," or "make it work *without* mmap," BTW?
;-) |
|
(0002800)
LewisR
2014-08-02 17:01
|
Scratch that last question, Paul. Please see 008F_05.TRP, attached.
Apache starts, and non-PHP requests respond fine. As soon as PHP is called, we get an "uncommitted memory allocated by MMAP" error thrown from LIBC065.
Getting closer, though (I think). At least we can start, now.
Thanks! |
|
(0002801)
psmedley
2014-08-02 22:14
|
hmmm... I going to have a crack at building a PHP 5.5 built with opcache enabled - at least then configure will try detect which mmap features are implemented rather than me hacking things manually... will let you know how I go.
fyi I can repeat the failure you're seeing here too |
|
(0002815)
LewisR
2014-08-14 04:54
|
Paul, my mmap seems to be:
Name : mmap
Arch : i386
Version : 20111102
Release : 8.oc00
Size : 778 k
Repo : installed
From repo : netlabs-rel-2rosenthals
Summary : A memory mapped emulation for OS/2-eComStation
License : unknown
Description: A memory mapped files emulation library.
Is this the same one against which you are building (or trying to build) the opcache module? I'm wondering if Yuri might be of some help in this regard, as I am coming up empty even trying to find sources for this.
Here's a quick snippet from a conversation earlier today concerning performance improvement with opcache (on Linux x64) with a local copy of a WordPress 3.9.2 site currently hosted on my box:
<snip>
I then installed Opcache (http://pecl.php.net/package/ZendOpcache) which
made quite a difference. Generation times of pages dropped to 0.3-0.5
seconds [from >2], with an occasional long load on the first hit and some
operations after that, but overall the site felt a lot more responsive.
<snip>
It seems that WordPress is a pig (well, that's not news), and static file cache only gets us part of the way. The PHP itself is just bulky (bloated).
Anyway, please let me know if I can help in any way, other than leaving you to get to this as time permits. ;-)
Cheers |
|
(0002818)
psmedley
2014-08-15 21:33
|
I don't understand right now why opcache isn't working.
Is it worth revisiting apc in the meanwhile? |
|
(0002819)
LewisR
2014-08-15 21:46
|
As a stopgap measure, it might be worth trying - as long as you do not have to invest significant time and energy, which would both be better spent here, for longer term reward.
I don't recall whether you looked at APC previously.
http://php.net/manual/en/apc.requirements.php seems to indicate that "all" that should be required to build APC is pcre (famous last words...LOL). If that is truly the case, then I say let's give it a shot, as *some* optimizer is better than *no* optimizer, and this code isn't getting any slimmer (sad to say).
Thanks! |
|
(0002820)
psmedley
2014-08-15 22:18
|
well i got an apc.dll pretty quickly.... but it crashes pthreads on startup.
Will have another look this afternoon - gotta get outta bed soon as we're off to dad's for lunch :) |
|
(0002821)
LewisR
2014-08-15 22:22
|
FYI, Yuri dropped a new pthreads just yesterday. Might be worth trying later on.
Enjoy lunch! |
|
(0002824)
psmedley
2014-08-17 07:13
|
I spoke with Dmik on IRC last night about the Permission Denied error using anonymous mmap. As he's currently working on mmap, he's suggested he should be able to take a look soon. I've given him a simple testcase that shows the issue. |
|
(0002825)
psmedley
2014-08-17 09:34
|
to be clearer:
[21:18:17] <dmik> Smedles: re
[21:18:38] <dmik> re mmap, I only implemented support for the offset field so far - and this works now
[21:19:16] <dmik> if you mail me more details about your failing mmap case - there is a good chance I'll look at it within the current update cycle as well |
|
(0002826)
LewisR
2014-08-19 03:45
(Last edited: 2014-08-19 03:45) |
Sometimes, it really pays to know the right people at the right time, and to try to do right by them (all the time). Thanks so much for bringing this up to him, and I'll drop him a note, as well.
This looks like we're moving in the right direction. Kind of like when Andy and I were working on getting a usable OpenVPN, and finally (as you may recall), it came down to the tap/tun driver only having tap support and no tunneling support; we could have tried different compilers and different options 'til the cows came home, and still we would have been all dressed up with nowhere to go. :-O
Cheers
|
|
(0002827)
psmedley
2014-08-19 09:54
|
<Smedles> btw any time yet to look at my mmap issue?
<truedmik> yes, I will do it this week while updating wpstk and mmap SVNs |
|
(0002828)
diver
2014-08-22 07:43
|
see ticket http://trac.netlabs.org/ports/ticket/32 for progress |
|
(0004257)
psmedley
2022-05-14 06:46
|
opcache is included in PHP 7 and above |
|
|
Notes |
(0003307)
Igor Vaskov
2019-06-20 13:08
|
Latest trap. |
|
(0003308)
psmedley
2019-06-23 09:25
|
Will try and look at this when I have time, busy on some non-OS/2 related home automation stuff right now |
|
(0003309)
psmedley
2019-07-05 21:51
(Last edited: 2019-07-06 05:55) |
diff of mysql 5.1.62 added. Will add a build log after it rebuilds
|
|
(0003310)
Steven Levine
2019-07-07 01:43
|
A few comments for posterity.
The trap is at:
i = cv->waiting;
because my_rw_unlock() has called
pthread_cond_signal( &rwp->writers );
and part or all of the rwp structure has been corrupted pr possibly freed and reused. An annotated .trp file is attached.
One thing stands out in the .trp file. There are no accessible DLLs listed. This cannot be true, since exceptq was able to read and disassemble the content of PTHR01.DLL |
|
(0003313)
Igor Vaskov
2019-07-09 20:19
|
I think it would be interesting to compare the way to implement the error-causing functionality without pthr01.dll and with it. Since previous versions not using pthr01 did not contain this error. |
|
(0003314)
psmedley
2019-07-10 09:30
(Last edited: 2019-07-10 11:09) |
@Igor you mean static linking pthreads? I can try that.
http://smedley.id.au/tmp/mysqld-20190710.zip
|
|
(0003315)
Igor Vaskov
2019-07-10 20:33
|
Yes. This version looks more stable. Uptime more than 8 hours. Previous did not work more than 2 hours without a trap. I continue testing the latest version. |
|
(0003316)
Igor Vaskov
2019-07-11 00:31
|
More stable. More than 10 hours of uptime, but the trap is in the same place. |
|
(0003317)
psmedley
2019-07-11 09:41
|
are you sure that's the right trp file?
Process: E:\APPS\MYSQL55\BIN\MYSQLD.EXE (06/16/2019 10:51:24 30,006,313) |
|
(0003318)
Igor Vaskov
2019-07-11 11:39
|
Sorry. This trp file incorrect. This is old verson. |
|
(0003319)
Igor Vaskov
2019-07-11 12:14
|
Once again, I apologize for the incorrect file. I have not updated the demon to the new version. However, the placebo effect and my belief in the best did the impossible. So the version that did not work before and two hours surpassed itself and worked 11 hours.
Now I updated everything correctly and continue testing. |
|
(0003320)
Igor Vaskov
2019-07-11 21:22
|
It is correct trp file from latest version. The trap is in the same place... |
|
(0003321)
Igor Vaskov
2019-07-12 11:27
|
In version 5.1.17 before the build 20140725 this trap was not. In build 2014072 ptpr01.dll appeared and an error appeared.
In version 5.1.17 prior to build 20140725, another method for treating threads was used, and there was no such error there.
Is it possible to use the old method of processing threads in the new version? |
|
(0003322)
psmedley
2019-07-13 08:21
(Last edited: 2019-07-13 08:21) |
The 'old' method was an older version of the pthreads library. Not sure I can even find an old copy of this lib.... of course, best solution is to fix pthreads...
PS what kernel do you use?
|
|
(0003324)
Igor Vaskov
2019-07-15 19:25
|
I use the OS / 4 core. |
|
(0003325)
Igor Vaskov
2019-07-15 19:35
|
Perhaps this error does not contain pthreads, but the code that refers to an already destroyed thread. Unfortunately, I do not have the opportunity to test this system with a different kernel (
Judging by the error, the function is called with a pointer to a non-allocated area of memory or already freed ... Perhaps this is a multitasking error. And so it appears at an arbitrary point in time. |
|
(0003326)
Steven Levine
2019-07-16 19:57
|
Have you tested with
PSD=ACPI.PSD /MAXCPU=1
IMO, this looks more like a possible SMP serialization issue, so running an a single CPU is a useful test.
Does running on a single CPU make the trap go away?
Another IMO, The actual failure has nothing to do with pthreads. There is some sort of buffer overflow or reuse of already freed memory in sql_parse. It just so happens to corrupt the pthreads mutex data structure.
Also, there is something strange going on with the OS4 kernel. Note that the .trp files list not DLLs in the
DLLs accessible from this process
This is very unusual.
|
|
(0003327)
Igor Vaskov
2019-07-17 12:03
|
Is it possible to run only MySQL in single-process mode? This is a production server, I can not reduce performance as much. |
|
(0003328)
Igor Vaskov
2019-07-17 16:34
|
I launched MySQL in single-processor mode (execmode.exe -sp). Waiting for results. |
|
(0003329)
Igor Vaskov
2019-07-17 21:54
|
The single-processor mode of the MySQL application did not lead to success. |
|
(0003330)
Igor Vaskov
2019-07-18 12:25
|
Steven,
I do not agree with the fact that this error has no relation to pthreads because it first appeared when a stable working version 5.1.17 was compiled with this library. There is nothing changed except the assembly with a newer libs. And the error occurred after that. |
|
(0003331)
Igor Vaskov
2019-07-18 21:23
|
I found that the dll files in the ANPM repository and in the netlabs zip archive differ in size and compile time. I installed the library from a zip archive and returned a version that uses external dll. And I'm testing again. |
|
(0003334)
Igor Vaskov
2019-07-19 10:00
|
Unfortunately... The trap is in the same place... |
|
(0003335)
Igor Vaskov
2019-08-25 23:32
|
I do not give up hope to launch a new version of MySQL. It may be useful to create a test version in which to enable the output of debugging information at the time of accessing the function in which an error occurs with an indication of the module in which it occurs. Perhaps the analysis of the code near the error will give an understanding.
There is also an assumption that the parameters are passed to the function by pointer, and for some reason, it is possible that the contents are corrupted inside the function. Then another function is called with the same pointer and an error occurs.
There is a proposal before calling the pthreads functions to copy the data to another memory area and give a link to it, unless of course the function itself implies changing the data within itself. |
|
(0003380)
Igor Vaskov
2020-01-16 22:19
|
Hi!
I update pthr01.dll. Problem is not resolve. |
|
|
Notes |
(0003135)
LewisR
2017-04-09 15:39
|
Tested with explicitly setting binary mode; same result.
ASCII transfers in both directions seem to work just fine, however, as does paging using the configured PAGER (less, in my case). |
|
(0003136)
psmedley
2017-04-09 20:11
|
I wonder if I broke this by modifying the code for non-blocking - will try and investigate this evening |
|
(0003137)
psmedley
2017-04-10 09:03
|
Yep, seems messing around with O_NONBLOCK broke ftp downloads. http://smedley.id.au/tmp/tnftp-20170410.zip seems to address |
|
(0003138)
LewisR
2017-04-10 22:39
|
Sorry, Paul, but this did not do it:
4-10-17 4:59 1,799,788 124 tnftp.exe
mget blue*
mget bluelion-4.9.1-en.7z [anpqy?]? y
227 Entering passive mode (192,168,100,2,207,82)
150 Opening BINARY mode data connection for file bluelion-4.9.1-en.7z (846488957
bytes).
0% | | 4054 KiB 3.80 MiB/s 03:31 ETAt
nftp.exe: Reading from network: Interrupted system call
0% | | -1 0.00 KiB/s --:-- ETA
426 Transfer failed.
Try again? |
|
(0003139)
psmedley
2017-04-11 09:33
|
i'll try with a bigger test file, the file I tried was quite small |
|
(0003140)
psmedley
2017-04-11 09:39
(Last edited: 2017-04-11 09:48) |
mget *.zip
mget client-4.x.zip [anpqy?]? y
227 Entering Passive Mode (192,168,1,200,252,222).
150 Opening BINARY mode data connection for client-4.x.zip (20234082 bytes).
100% |***********************************| 19759 KiB 7.22 MiB/s 00:00 ETA
226 Transfer complete.
20234082 bytes received in 00:02 (7.21 MiB/s)
Any environment variables set or anything to modify tnftp from the default settings?
i'm just using:
tnftp 192.168.1.200 21
to connect to a local ftp server
|
|
(0003141)
LewisR
2017-04-12 21:18
|
First, the exe I'm using has an md5sum of:
2ee94ed85add1385fe2644e407615bc1
(just to be sure we're using the same build)
Next, I started tnftp from a prompt, then:
o hawking
<username>
<password>
cd /ftp/arcanoae/bluelion/betas
and the above.
Hawking is on the local LAN segment, so there's no firewall or NAT traversal to be made. I'll try with a smaller file...
Nope:
mget *2017-04*
mget rpm-yum-base-os2-i686-2017-04-08.exe [anpqy?]? y
227 Entering passive mode (192,168,100,2,220,20)
150 Opening BINARY mode data connection for file rpm-yum-base-os2-i686-2017-04-0
8.exe (44382826 bytes).
0% | | 0 0.00 KiB/s --:-- ETAt
nftp.exe: Reading from network: Interrupted system call
0% | | -1 0.00 KiB/s --:-- ETA
426 Transfer failed.
mget rpm-yum-base-os2-i686-2017-04-08.zip [anpqy?]? n
binary
200 OK
get rpm-yum-base-os2-i686-2017-04-08.zip
local: rpm-yum-base-os2-i686-2017-04-08.zip remote: rpm-yum-base-os2-i686-2017-0
4-08.zip
227 Entering passive mode (192,168,100,2,220,31)
150 Opening BINARY mode data connection for file rpm-yum-base-os2-i686-2017-04-0
8.zip (44343605 bytes).
13% |**** | 5798 KiB 1.37 MiB/s 00:26 ETAt
nftp.exe: Reading from network: Interrupted system call
0% | | -1 0.00 KiB/s --:-- ETA
426 Transfer failed.
Local filesystem is JFS, though that should not matter, in this case.
Smaller test:
-rwxrwxrwx 1 ftp -A--N 5426 Aug 8 2014 zwrotlogs.txt
226 Transfer complete.
get zwrotlogs.exe
local: zwrotlogs.exe remote: zwrotlogs.exe
227 Entering passive mode (192,168,100,2,220,87)
150 Opening BINARY mode data connection for file zwrotlogs.exe (87928 bytes).
100% |***********************************| 87928 1.94 MiB/s 00:00 ETA
226 Transfer complete, closing data connection.
87928 bytes received in 00:00 (1.71 MiB/s)
That works, as does:
get whois.exe
local: whois.exe remote: whois.exe
227 Entering passive mode (192,168,100,2,220,106)
150 Opening BINARY mode data connection for file whois.exe (135867 bytes).
100% |***********************************| 132 KiB 132.68 KiB/s --:-- ETA
226 Transfer complete, closing data connection.
135867 bytes received in 00:00 (132.68 KiB/s)
So, it would seem that there is some size thing happening somewhere. Both of those smaller binaries came down intact. |
|
(0003142)
psmedley
2017-04-25 04:41
(Last edited: 2017-04-25 04:57) |
ok, finally got around to trying to reproduce and succeeded on a larger file :)
tnftp.exe: Reading from network: Interrupted system call
OK, please try http://smedley.id.au/tmp/tnftp-20170425.zip
read() was failing with EINTR - added some code to workaround this :)
|
|
(0003143)
psmedley
2017-04-25 09:53
|
OK upload was similarly broken, zip refreshed with the fix |
|
(0003144)
psmedley
2017-04-25 10:04
|
hmmmm except the file ends up corrupt.... need to think more on this and why read() is reporting EINTR and how to prevent this... setting the socket non-blocking didn't help.
I changed:
while (bufrem > 0) {
inc = read(infd, buf, MIN((off_t)bufsize, bufrem));
if ((inc <= 0) && (errno != EINTR))
goto copy_done;
bytes += inc;
bufrem -= inc;
to:
while (bufrem > 0) {
inc = read(infd, buf, MIN((off_t)bufsize, bufrem));
if (inc <= 0)
goto copy_done;
bytes += inc;
bufrem -= inc;
thinking now, of course this corrupts the file as inc is later used to change the amount of data to still be read, I probably need to reset inc to 0 if EINTR is received. Will play more tomorrow, at least I know where it's failing :) |
|
(0003149)
LewisR
2017-11-12 22:00
|
Reminder sent to: Steven Levine
Steve, as we were looking at this as a poss9ible replacement for IBM's FTP in ArcaOS, when you have a few minutes to look at the code, your thoughts would be appreciated. The server email hiccup today served as a good reminder that this issue was still sort of hanging. |
|
(0003202)
LewisR
2018-10-16 02:17
|
This has become something of an issue (again), Paul. FWIW, I attempted to download a 2MB file from Hobbes with the 20170425 build, and got a 56KB chunk before "interrupted system call" was reported. Further testing with tracing (-t) and debug enabled showed:
---> RETR qk.zip
150 Opening BINARY mode data connection for qk.zip (2103580 bytes).
15% |***** | 322 KiB 314.54 KiB/s 00:05 ETAt
nftp.exe: Reading from network: Interrupted system call
0% | | -1 0.00 KiB/s --:-- ETA
426 Failure writing network stream.
xferbuf 512k
Socket buffer sizes: send 524288, receive 524288.
get qk.zip
local: qk.zip remote: qk.zip
---> SIZE qk.zip
213 2103580
---> PASV
227 Entering Passive Mode (128,123,34,6,44,253).
tnftp.exe: Unable to set sndbuf size 524288: No buffer space available
tnftp.exe: Unable to set rcvbuf size 524288: No buffer space available
---> RETR qk.zip
150 Opening BINARY mode data connection for qk.zip (2103580 bytes).
32% |*********** | 677 KiB 328.26 KiB/s 00:04 ETAt
nftp.exe: Reading from network: Interrupted system call
0% | | -1 0.00 KiB/s --:-- ETA
426 Failure writing network stream.
xferbuf 256k
Socket buffer sizes: send 262144, receive 262144.
get qk.zip
local: qk.zip remote: qk.zip
---> SIZE qk.zip
213 2103580
---> PASV
227 Entering Passive Mode (128,123,34,6,105,135).
tnftp.exe: Unable to set sndbuf size 262144: No buffer space available
tnftp.exe: Unable to set rcvbuf size 262144: No buffer space available
---> RETR qk.zip
150 Opening BINARY mode data connection for qk.zip (2103580 bytes).
13% |**** | 276 KiB 270.58 KiB/s 00:06 ETAt
nftp.exe: Reading from network: Interrupted system call
0% | | -1 0.00 KiB/s --:-- ETA
426 Failure writing network stream.
xferbuf 128k
Socket buffer sizes: send 131072, receive 131072.
get qk.zip
local: qk.zip remote: qk.zip
---> SIZE qk.zip
213 2103580
---> PASV
227 Entering Passive Mode (128,123,34,6,148,81).
---> RETR qk.zip
150 Opening BINARY mode data connection for qk.zip (2103580 bytes).
2% | | 45540 44.07 KiB/s 00:45 ETAt
nftp.exe: Reading from network: Interrupted system call
0% | | -1 0.00 KiB/s --:-- ETA
426 Failure writing network stream.
xferbuf 64k
Socket buffer sizes: send 65536, receive 65536.
get qk.zip
local: qk.zip remote: qk.zip
---> SIZE qk.zip
213 2103580
---> PASV
227 Entering Passive Mode (128,123,34,6,92,130).
---> RETR qk.zip
150 Opening BINARY mode data connection for qk.zip (2103580 bytes).
1% | | 34500 32.74 KiB/s 01:01 ETAt
nftp.exe: Reading from network: Interrupted system call
0% | | -1 0.00 KiB/s --:-- ETA
426 Failure writing network stream.
I would have expected to have enough buffer space for 256K, even if I didn't for 512K. Not having 64K doesn't seem reasonable. |
|
|
Notes |
(0002089)
Steven Levine
2011-12-31 00:16
|
Since the pathname in the the error message is relative, it implies that the problem is with EAs on the destination file. What does the dir command have to say out this file? |
|
(0002091)
LewisR
2011-12-31 03:37
|
Volume in drive J is DATA Serial number is 657E:D5BA
Directory of J:\CGP_Backup\Communigate\Accounts\lgrosenthal.macnt\OS2 Wireless
.folder\all-messages.mdir\102097-S_______-20031123115013-89
8-01-09 23:44 3,538 0 102097-S_______-20031123115013-89
3,538 bytes in 1 file and 0 dirs
4,096 bytes allocated
16,920,453,120 bytes (15GB) free
No EAs, as expected. Only the archive bit is set on the backup file, as well. Do you think this could be some underlying filesystem corruption? The volume had already undergone that long chkdsk pass which we discussed on one of our mutual lists (that was 10/21, IIRC).
The thing is that this file was already copied, and had no EAs on eithe rthe original or the first copy. It hasn't changed since then, so rsync should have just skipped over it (unless it had some difficulty accessing the file for comparison).
The only things in the exclude list are the queues & logs directories, too, BTW. Oh, and no EAs on the directory itself (source or destination), either. |
|
(0002098)
Steven Levine
2011-12-31 05:35
|
Let's see if
http://mantis.smedley.info/file_download.php?file_id=221&type=bug
can tell us anything. It adds the failing EA name to the error report. |
|
(0002118)
LewisR
2011-12-31 21:27
|
Hehehe...
No details, and no error (at least, not this error) running rsync-3.0.8-20111230-shl. Let's close this as resolved, unless you think that whatever changed between 20110419 and 20111231 regarding xattrs could not have addressed this.
To test, after the first rsync pass didn;t copy any files (Doh! because they were already there!), I deleted about 50 of the backup copies (including the sample, referenced in this bug) in the problem directory, and waited for the next hourly pass. The entire group of files copied without error.
Thanks! |
|
(0002119)
Steven Levine
2011-12-31 21:38
|
I recommend we leave this ticket open for a bit. I did not change anything that could have resolved the error you reported. |
|
(0002158)
LewisR
2012-01-09 19:24
|
Yep... Hit it again:
2012/01/09 13:14:29 [8556] [sender] unigetxattr: DosQueryPathInfo(CGP_Backup/Communigate/Domains/driven-zen.org/bulkimages.macnt/INBOX.mdir/42350-________-20100509231812-372, FIL_QUERYEASFROMLIST) for FLAGS failed with error 8 at lib/sysxattrs.c(241)
This time, no whitespaces in the path, and this file should not have been in use by any other process, as it's:
1. An old message file (2010);
2. Already in the backup directory (CGP_Backup);
3. Unchanged since originally backed up, and the hourly backup pass would not have had this open at the same time.
A dir on the file shows:
Volume in drive J is DATA Serial number is 657E:D5BA
Directory of J:\CGP_Backup\Communigate\Domains\driven-zen.org\bulkimages.macnt
\INBOX.mdir\42350-________-20100509231812-372
5-09-10 19:18 12,387 124 42350-________-20100509231812-372
12,387 bytes in 1 file and 0 dirs
The 124 bytes of EAs appear to all be LIBC EAs.
rsync-3.0.8-20111230-shl made two attempts (it would appear from the log) to access this file and two others in that directory, all of which failed with the same error. These files were not copied to the destination at all.
rsync command used:
c:\opt\rsync\bin\rsync.exe --archive --xattrs --os2-perms --del --itemize-changes --times --stats --human-readable --log-file=c:/var/log/rsync_backup_j.log j:/ e:/
I don't know how the LIBC EAs would have even been attached to the original file, as really none of the CGP mail files should have any EAs on them, however, it appears that every file touched by rsync now has LIBC EAs attached. In fact, looking more closely, I find that I actually have duplicate files, one version without EAs and another with EAs (the ones with EAs do *not* exist in the live CGP mail directory). Here's an example (from a different mailbox backup):
10-05-11 2:58 75,268 0 1-S_______-20111005065823-1262
10-05-11 2:58 75,268 124 1-________-20111005065823-1262
10-05-11 3:21 32,351 0 2-S_______-20111005072112-776
10-05-11 3:21 32,351 124 2-________-20111005072112-776
10-05-11 3:44 3,839 0 3-S_______-20111005074412-104
10-05-11 3:44 3,839 124 3-________-20111005074412-104
10-05-11 4:33 13,396 0 4-S_______-20111005083312-322
10-05-11 4:33 13,396 124 4-________-20111005083312-322
10-05-11 9:00 16,640 0 5-S_______-20111005130031-639
10-05-11 9:00 16,640 124 5-________-20111005130031-639
10-05-11 9:06 3,821 0 6-S_______-20111005130636-109
10-05-11 9:06 3,821 124 6-________-20111005130636-109
10-05-11 9:39 47,094 0 7-S_______-20111005133952-785
10-05-11 9:39 47,094 124 7-________-20111005133952-785
10-05-11 10:24 15,184 0 8-S_______-20111005142455-555
10-05-11 10:24 15,184 124 8-________-20111005142455-555
10-05-11 10:28 2,587 0 9-S_______-20111005142811-62
10-05-11 10:45 649 0 10-S_______-20111005144514-15
and the live mailbox:
10-05-11 2:58 75,268 0 1-S_______-20111005065823-1262
10-05-11 3:21 32,351 0 2-S_______-20111005072112-776
10-05-11 3:44 3,839 0 3-S_______-20111005074412-104
10-05-11 4:33 13,396 0 4-S_______-20111005083312-322
10-05-11 9:00 16,640 0 5-S_______-20111005130031-639
10-05-11 9:06 3,821 0 6-S_______-20111005130636-109
10-05-11 9:39 47,094 0 7-S_______-20111005133952-785
10-05-11 10:24 15,184 0 8-S_______-20111005142455-555
10-05-11 10:28 2,587 0 9-S_______-20111005142811-62
10-05-11 10:45 649 0 10-S_______-20111005144514-15
10-05-11 10:45 5,539 0 11-S_______-20111005144552-141
10-05-11 11:26 647 0 12-S_______-20111005152616-15
10-05-11 11:58 649 0 13-S_______-20111005155826-15
10-05-11 12:10 131,806 0 14-S_______-20111005161034-1789
10-05-11 12:22 16,963 0 15-S_______-20111005162212-399
10-05-11 13:09 21,189 0 16-S_______-20111005170920-490
10-05-11 13:25 10,021 0 17-S_______-20111005172505-331
10-05-11 13:41 3,335 0 18-S_______-20111005174144-98
Not sure why the "S" was replaced with a "_" when the EAs were tacked on. I'm happy to open a separate bug for the duplicate files or perhaps we should create a meta-bug for EA-related issues? |
|
(0002159)
LewisR
2012-01-09 19:33
|
I understand why I have duplicate files. The filenames changed as a result of the state of the message changing (not read -> read). Now to figure out how to get rsync to replace the old versions with the ones of changed state, or better, skip them entirely. Still, we should not be *adding* EAs to the copied files when --xattrs is specified, should we? |
|
(0002162)
Steven Levine
2012-01-10 08:36
|
I am not sure what you mean by "we should not be *adding* EAs to the copied files when --xattrs is specified." Rsync sync's EAs. It does not add EAs that do not exist at the source. If something "added" EAs to the source file, it is unlikely that it was rsync.
Note that there may be an errant libc based app out there that does add EAs to every file it accesses. I have had one report of a user system that had libc EAs attached to every file on the boot volume. |
|
(0002163)
LewisR
2012-01-10 16:54
|
CGP is not a gcc app. None of CGP's files have *any* EAs on them, yet when running rsync.exe --xattrs, *all* backed up copies get libc EAs (exactly 124 bytes) attached.
This, though, as I said in comment #2159, is not the real issue insofar as multiple copies of the same content are concerned. It *is*, however, an issue either for libc or rsync, apparently.
What I've found is that while I haven't been able to get 3.0.8 to tack on the EAs (perhaps those came from a previous build?) it *will* consistently do it when creating new directories. I'll open a separate issue for that. |
|
(0002164)
Steven Levine
2012-01-10 21:33
|
I finally figured out what you did to generate the EAs. Way back when you were running rsync without --xattrs. This means that libc will add the libc private EAs and rsync will leave them alone. IMO, this is appropriate. It's not different that if rsync was run without --perms. The destination file permissions will be set to to runtime defaults.
Once you started using --xattrs, rsync brought the EAs into sync for existing files. Files that no longer existed at the source remaining unchanged. If you want them to go away you can use my StripLibcEAs script or the equivalent.
Note that libc064 supports the LIBC_UNIX_EAS environment variable which allows the libc EAs logic to be suppressed for specific volumes. Unfortunately, libc064 is not yet sufficiently stable for rsync use, so we can not yet use this.
The directory EAs are a known issue. I won't bore you with the gory details, but currently it takes two rsync runs to get the directory EAs into sync. Once we have a working libc with LIBC_UNIX_EAS support, I might be able to use this to avoid the spurious EAs. |
|
(0002171)
LewisR
2012-01-11 02:55
|
Okay. Understood. So, we're still back where we started in this bug, trying to figure out why we get the error 8 on some files and not others. Per my PM, as long as we're not getting EA data *replaced*, the fact that we're adding 124 extra bytes of EAs is of little consequence. The presence (or lack thereof) of these EAs is not what is causing the multiple copies of the CGP files, as we've determined, which was my initial concern.
Thanks for the clarification. |
|
(0002416)
asavage
2013-03-12 17:51
(Last edited: 2013-03-12 18:12) |
Where can I learn more about LIBC_UNIX_EAS ?
Has libc065.dll support for the env var LIBC_UNIX_EAS
I see at:
http://svn.netlabs.org/libc/ticket/43
"the value of the variable is on the forms:
set LIBC_UNIX_EAS=!c,!e-f,d,g-h
"
Does this work now?
Oh, and where may I find the StripLibcEAs script?
|
|
(0002417)
Steven Levine
2013-03-12 20:38
|
There's not a lot of external documentation.
http://svn.netlabs.org/libc/search?q=LIBC_UNIX_EAS
will tell you a bit more than you already know. As the query shows, the last change to the support was http://svn.netlabs.org/libc/changeset/3697.
LIBC065 was the first release to formally support the feature.
I'll send you a copy of StripLibcEAs privately with some comments. It's not 100% generic. |
|
(0003153)
Steven Levine
2017-11-29 19:41
|
Please retest with
http://www.warpcave.com//betas/rsync-3.0.9.1-20171111-shl.zip |
|
|
Notes |
(0002182)
Buck
2012-01-21 06:20
|
I came looking to see if this had yet been reported as I am seeing the same thing. If I don't set perllib_prefix then it finds the .pm files fine when run on the same drive as it searches for /perl5/lib on the root of the drive but when on another drive having to set the perllib_prefix to be able to find them fails as above. |
|
(0002183)
shmuel
2012-01-22 01:16
|
If I issue these commands
PATH F:\perl5\bin;%PATH%
SET BEGINLIBPATH=F:\perl5\bin
SET MANPATH=F:\Perl5\man
SET PERLLIB=F:\Perl5\lib
SET PERLLIB_PREFIX=
SET PERL_SH_DIR=F:/Perl5/bin
then the perl -V works, but a test script gives me an error message:
[h:\]testpl
Can't locate warnings.pm in @INC (@INC contains: F:\Perl5\lib /perl5/lib/5.10.0/os2 /perl5/lib/5.10.0 /perl5/lib/site_perl/5.10.0/os2 /perl5/lib/site_perl/5.10.0 .) at H:\UTILITY/testpl.cmd line 3.
BEGIN failed--compilation aborted at H:\UTILITY/testpl.cmd line 3.
A dir shows that the mopdule exists:
[h:\]dir /s f:\perl5\warnings.pm
Volume in drive F is ECS BOOT0 Serial number is 29EE:1415
Directory of F:\perl5\lib\5.14.2\warnings.pm
1-03-12 3:37 18,672 124 warnings.pm
18,672 bytes in 1 file and 0 dirs 18,944 bytes allocated
Directory of F:\perl5\lib\5.14.2\encoding\warnings.pm
1-03-12 3:37 6,236 124 warnings.pm
6,236 bytes in 1 file and 0 dirs 6,656 bytes allocated
kLIBC Pathrewriters maps /perl5 to F:\perl5 |
|
(0002184)
Buck
2012-01-22 01:46
|
You need to check your testpl again I think... it is using the wrong Perl:
/perl5/lib/5.10.0 |
|
(0002185)
shmuel
2012-01-22 03:43
|
You're right; EXTPROC had an absolute path. When I changed it to just perl -options and left PERLLIB_PREFIX unset it worked. The bypass will cause harmless warnings installing CPAN modules, but I can live with that. |
|
(0002186)
psmedley
2012-01-22 08:20
|
I wonder if the code that handles PERLLIB_PREFIX can't handle the fact that the installation path is /perl5 and it's trying to change a drive letter?
I wonder what the best solution is - change the default installation to u:/perl5 and maybe PERLLIB_PREFIX will work correctly, or leave it as /perl5 and suggest the use of the klibc rewriter and that people NOT use PERLLIB_PREFIX? |
|
(0002188)
shmuel
2012-01-22 12:20
|
Without PERLLIB_PREFIX I have problems building CPAN modules:
[h:\vendors\cpan\digest-sha1-2.11]perl Makefile.PL
Writing Makefile for Digest::SHA1
Writing MYMETA.yml
[h:\vendors\cpan\digest-sha1-2.11]U:\extras\bin\make
Skip blib/lib/Digest/SHA1.pm (unchanged)
gcc -c -DDOSISH -DOS2=2 -DEMBED -I. -I/usr/local/include -O2 -fomit-frame-pointer -falign-loops=2 -falign-jumps=2 -falign-functions=2 -s -DVERSION=\"2.11\"
-DXS_VERSION=\"2.11\" -Zdll "-I/perl5/lib/5.14.2/os2/CORE" SHA1.c
In file included from SHA1.xs:8:
/perl5/lib/5.14.2/os2/CORE/perl.h:2577:27: os2ish.h: No such file or directory
In file included from /perl5/lib/5.14.2/os2/CORE/perl.h:5040,
from SHA1.xs:8:
/perl5/lib/5.14.2/os2/CORE/proto.h:266: error: parse error before '*' token
In file included from /perl5/lib/5.14.2/os2/CORE/perl.h:5070,
from SHA1.xs:8:
/perl5/lib/5.14.2/os2/CORE/intrpvar.h:88: error: parse error before "PL_statbuf"
/perl5/lib/5.14.2/os2/CORE/intrpvar.h:88: warning: data definition has no type or storage class
/perl5/lib/5.14.2/os2/CORE/intrpvar.h:89: error: parse error before "PL_statcache"
/perl5/lib/5.14.2/os2/CORE/intrpvar.h:89: warning: data definition has no type or storage class
SHA1.xs: In function `XS_Digest__SHA1_clone':
SHA1.xs:488: warning: initialization discards qualifiers from pointer target type
make.exe: *** [SHA1.o] Error 1 |
|
(0002190)
Buck
2012-01-22 22:36
|
KLIBCpathrewriter does appear to work... don't know why I didn't think to try it before other than I haven't explicitly used it very often.
Adding the drive as u: may fix it but it is odd how it is showing up.
First it adds a /o to the path then it drops the .2 from the path then it adds the /o again to the next path. I hate to say drop the PERLLIB_PREFIX as it has been around for a long time and is in almost any write up of how to setup Perl on OS/2 and dropping it would then cause all the documentation to cause people to go astray... on the other hand, klibcpathrewriter seems to work so hate to see unnecessary work done trying to figure it out, especially if it is more than just adding the drive letter. |
|
(0002191)
shmuel
2012-01-23 00:01
|
I wouldn't mind saying to drop PERLLIB_PREFIX if that worked, but it breaks the CPAN build process. We need a fix or bypass that doesn't break anything else. |
|
(0002201)
shmuel
2012-01-27 02:28
|
I get a little farther if I use an exlicit drive on the left side of SET PERLLIB_PREFIX=u:/perl5/lib;F:/perl5/lib, but I still get an error message from gcc:
gcc -c -DDOSISH -DOS2=2 -DEMBED -I. -I/usr/local/include -O2 -fomit-frame-pointer -falign-loops=2 -falign-jumps=2 -falign-functions=2 -s -DVERSION=\"2.131\"
-DXS_VERSION=\"2.131\" -Zdll "-I/perl5/lib/5.14.2/os2/CORE" -DUSE_PPPORT_H Dumper.c
gcc: gcc: error executing U:/usr/i386-pc-os2-emx/bin/as.exe: No such file or directory
I verified that the file exists:
[g:\os2]dir U:\usr\i386-pc-os2-emx\bin\as.exe
Volume in drive U is SMEDLEY Serial number is 3EBD:8001
Directory of U:\usr\i386-pc-os2-emx\bin\as.exe
6-11-07 9:19 212,992 0 as.exe |
|
(0002232)
DB1
2012-04-02 11:43
|
A little late to the party :-)
What PERLLIB_PREFIX does to mess things up depends on the difference in lengths of the two strings. if the replacement is two characters longer then it will drop the last two characters. I have tried using PERL5LIB which gets around the truncation problem but even with the drive letters CPAN still fails with not finding some fairly basic thing like "strict". *And* it fails if invoked from a different drive. :-( |
|
(0002233)
DB1
2012-04-05 14:38
|
I can get a bit further by setting PERLLIB_PREFIX=/perl5;/perl5 having installed into the root of a drive. So the broken substitution does not come into play. I then used klibcrewriter to change /perl5 into t:/perl5.
Next problem in trying to install *anything* from CPAN is all tests fail always. And if there is a compile involved I get the "no such file os2ish.h" message. This is because it does not exist. The file ...../CORE/os2ish.h is a soft link to os2/os2ish.h but it does not exist. The link implies that there is a ...../CORE/os2 directory containing os2ish.h but that does not exist either. In 5.8.2 it is a real file in CORE. |
|
(0002272)
Steven Levine
2012-05-20 19:41
|
I heard about the @INC issue from someone trying to use my mapsymw.pl on 5.14.2. This PERLLIB_PREFIX mapping issue seems to be specific to 5.14.2
Given a 5.14.2 setup of
PERL_BADLANG=0
PERL_SH_DIR=D:\BIN
PERLLIB_PREFIX=/perl5/lib;D:\usr\perl514\LIB
BeginLIBPATH=D:\USR\PERL514\BIN;
the @INC truncation is obvious
>perl -e "map { print \"$_\n\" } @INC"
D:/usr/perl514/LIB/site_perl/5.
D:/usr/perl514/LIB/site_per
D:/usr/perl514/LIB/5.
D:/usr/perl514/LI
D:/usr/perl514/LIB/s
.
The same code on 5.10.0 claims @INC is OK.
>perl -e "map { print \"$_\n\" } @INC"
D:/usr/perl510/LIB/5.10.0/os2
D:/usr/perl510/LIB/5.10.0
D:/usr/perl510/LIB/site_perl/5.10.0/os2
D:/usr/perl510/LIB/site_perl/5.10.0
.
The type of slash does not seems to matter. |
|
(0002273)
psmedley
2012-05-21 09:05
|
There are no obvious differences in os2.c between perl 5.10.0 and 5.14.2 that would explain this.
Seems the easiest fix would be to change 5.14.2 to default to u:/perl5 as I'd wager that will take care of the PERLLIB_PREFIX issue |
|
(0002274)
Steven Levine
2012-05-21 19:19
|
I suspect the issue is the significant rewrite to S_incpush in perl.c. Near line 4432 we have
libdir = newSVpvn(PERLLIB_MANGLE(dir, len), len);
If I am reading the code right, this will do the substitution and create a new string chopping it off at the old length. What I don't understand is why 5.10.0 and older versions seem to work correctly since the code is similar.
What I suspect will correct the behavior is something like
const char *dir2 = PERLLIB_MANGLE(dir, len);
libdir = newSVpvn(dir2, strlen(dir2)); |
|
(0002275)
DB1
2012-05-22 18:12
|
Steven - I took the liberty of copying the above to the perl NG where I am having other problems with this port and CPAN. Ben Morrow, who knows *far* more about perl than I do, says:
===============================
In 5.10.0 the code says
if ( usesep && (s = strchr(p, PERLLIB_SEP)) != NULL ) {
sv_setpvn(libdir, PERLLIB_MANGLE(p, (STRLEN)(s - p)),
(STRLEN)(s - p));
p = s + 1;
}
else {
sv_setpv(libdir, PERLLIB_MANGLE(p, 0));
p = NULL; /* break out */
}
whereas in 5.14.2 it omits the 'usesep' condition, and only has
if (len) {
/* I am not convinced that this is valid when PERLLIB_MANGLE is
defined to so something (in os2/os2.c), but the code has been
this way, ignoring any possible changed of length, since
760ac839baf413929cd31cc32ffd6dba6b781a81 (5.003_02) so I'll leave
it be. */
libdir = newSVpvn(PERLLIB_MANGLE(dir, len), len);
} else {
libdir = newSVpv(PERLLIB_MANGLE(dir, 0), 0);
}
I don't know under what circumstances 'usesep' is supposed to be set,
but maybe taking the second branch prevents the truncation? The
implementation of PERLLIB_MANGLE is, um, scary; it appears to keep a
record of the old length in a global, for some reason I can't quite
follow.
================================ |
|
(0002276)
Steven Levine
2012-05-22 18:43
|
Hi DB1,
Taking the path that invokes
libdir = newSVpv(PERLLIB_MANGLE(dir, 0), 0);
would avoid the truncation and that what might occur in 10.0 and older. You can think of newSVpv as a smart strcpy and newSVpvn as a smart strncpy. The SV objects are smart reference counted string objects.
usesep means that the input is a list of paths that need to be split and the 10.0 code loops to do this. In 14.2 there's a new outer function that does the split and the loop no longer exists. It needs to be tested, but I think my suggested fix is safe.
I don't see the global you are referring to. Got a file and line#? |
|
(0002277)
DB1
2012-05-22 20:02
|
Sorry Steven - I posted all Ben said between the ======== lines. |
|
(0002278)
Steven Levine
2012-05-22 22:45
|
Does Ben have commit access to the Perl repo? If so, perhaps it makes sense for us to discuss my recommendation on comp.os.os2.misc or elsewhere. |
|
(0002288)
psmedley
2012-06-04 09:30
|
OK Steven's patch works with 5.16.0:
Examples of output below:
[U:\DEV]set PERLLIB_PREFIX=u:/perl5/lib;D:\usr\perl514\LIB
5.16.0 without Steven's patch:
[U:\DEV]perl -e "map { print \"$_\n\" } @INC"
D:/usr/perl514/LIB/site_perl/5.16
D:/usr/perl514/LIB/site_perl/
D:/usr/perl514/LIB/5.16
D:/usr/perl514/LIB/
D:/usr/perl514/LIB/sit
.
5.16.0 with Steven's patch:
[U:\DEV]perl -e "map { print \"$_\n\" } @INC"
D:/usr/perl514/LIB/site_perl/5.16.0/os2
D:/usr/perl514/LIB/site_perl/5.16.0
D:/usr/perl514/LIB/5.16.0/os2
D:/usr/perl514/LIB/5.16.0
D:/usr/perl514/LIB/site_perl
. |
|
(0002289)
psmedley
2012-06-04 09:31
|
Test build is at http://smedley.id.au/perl-5.16.0-os2-20120604.zip |
|
(0002293)
DB1
2012-06-08 13:22
(Last edited: 2012-06-08 13:25) |
Are, but it does not actually work :-(
Built under os2
Compiled at Jun 4 2012 18:56:00
%ENV:
PERLDOC="-otext"
PERLLOC="u:\perl5"
PERLLOC2="u:/perl5"
PERL_SH_DIR="u:\BIN"
@INC:
u:/perl5/lib/site_perl/5.16.0/os2
u:/perl5/lib/site_perl/5.16.0
u:/perl5/lib/5.16.0/os2
u:/perl5/lib/5.16.0
u:/perl5/lib/site_perl
.
[U:\]perl -MCPAN -e shell
Can't locate Cwd.pm in @INC (@INC contains: U:u:/perl5/lib/site_perl/5.16.0/os2
U:u:/perl5/lib/site_perl/5.16.0 U:u:/perl5/lib/5.16.0/os2 U:u:/perl5/lib/5.16.0
U:u:/perl5/lib/site_perl .) at u:/perl5/lib/5.16.0/os2/File/Spec/OS2.pm line 215
.
BEGIN failed--compilation aborted at u:/perl5/lib/5.16.0/CPAN.pm line 17.
Compilation failed in require.
BEGIN failed--compilation aborted.
Edit: It is putting the current drive letter on the front of each path. I just tried from t:/tmp
[T:\tmp]perl -MCPAN -e shell
Can't locate Cwd.pm in @INC (@INC contains: T:u:/perl5/lib/site_perl/5.16.0/os2
|
|
(0002294)
Steven Levine
2012-06-08 15:19
|
This is most likely a side-effect to the new relocatable @INC feature. Our port may be using *ix semantics to determine if the path is absolute.
I'll see it I can track this down later.
I will need a copy of the 5.16.0 .diffs for this. |
|
(0002295)
Steven Levine
2012-06-08 15:53
|
That's not it. Take a look at CPAN.pm line 17
$inc = File::Spec->rel2abs($inc) unless ref $inc;
Someone broke our rel2abs when they refactored the code for 5.16.0.
>perl -e "use File::Spec ; print File::Spec->rel2abs('d:/foo')"
J:d:/foo
It looks like they tried to add code to supply a drive letter. |
|
(0002296)
Steven Levine
2012-06-08 16:17
|
It should be sufficient to integrate the Win32 file_name_is_absolute(). This will add support for UNC pathnames which is a good thing.
FWIW, this fix along with any other .pm fixes should be passed upstream to the Perl maintainers. |
|
(0002297)
DB1
2012-06-08 18:09
|
Absolutely, otherwise an innocently applied update to a perl module breaks the fix. |
|
(0002298)
psmedley
2012-06-08 22:52
|
I will take a look at the patches tonight - it's possible I broke things whilst trying to fix rel2abs for Shmuel.
On the subject of submitting patches - if the Perl guys will accept them, I'm happy to submit, but many projects make it so friggin hard to submit patches that it's not worth the effort |
|
(0002299)
psmedley
2012-06-09 00:01
|
http://smedley.id.au/perl-5.16.0.diff has the latest diff |
|
(0002300)
Steven Levine
2012-06-09 01:29
(Last edited: 2012-06-09 01:30) |
The attached OS2.pm can replace dist\File\Spec\OS2.pm and fixes rel2abs based on my testing. Functionally all I did was merge the Win32 version of file_name_is_absolute along with the associated variable definitions into the previously patched OS2.pm
perl -MCPAN -e shell works, although the CPAN readline has issues that will be reported in another ticket.
Those that need it now can replace lib\5.16.0\os2\File\Spec\OS2.pm with this file.
|
|
(0002302)
DB1
2012-06-09 10:45
|
What with readline? I am back to the "no test will run" scenario :-( |
|
(0002305)
Steven Levine
2012-06-09 18:37
|
The readline issue is on hold. With, I suspect, the rel2abs fixes, CPAN now claims that $term does not support history. Before this a Ctrl-R generated perl error messages.
Which ticket are you referring to with your "no test will run" comment? I've seen some of the newsgroup postings, but they contain too much cruft for me to attempt to replicate the failure here. |
|
(0002307)
DB1
2012-06-10 14:56
|
I don't think I raised one here.
Basically try and install anything as soon as it gets to running the test it just skips them all. There is a problem *somewhere* in makemaker and/or Test::* things. One of the things I was trying to sort with Ben's help.
U:/PERL5/BIN/PERL.EXE "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/basic.t ............... No subtests run
t/like-exception.t ...... No subtests run
t/release-pod-syntax.t .. No subtests run |
|