Bug 31233
— Обновить до последней версии 3.2.3
Summary:
Обновить до последней версии 3.2.3
|
|
||||||||||||||||||||||||||||||||||||||||||||||
|
|
Note |
Параметр сокета SO_ERROR
Когда на сокете происходит ошибка, модуль протокола в ядре, происходящем от Беркли, присваивает переменной so_error для этого сокета одно из стандартных значений Unix Exxx. Это так называемая ошибка, требующая обработки (pending error) для данного сокета. Процесс может быть немедленно оповещен об ошибке одним из двух способов:
1. Если процесс блокируется в вызове функции select (см. раздел 6.3), ожидая готовности данного сокета к чтению или записи, функция select возвращает управление и уведомляет процесс о соответствующем состоянии готовности.
2. Если процесс использует управляемый сигналом ввод-вывод (см. главу 25), для него или для группы таких процессов генерируется сигнал SIGIO.
Процесс может получить значение переменной so_error, указав параметр сокета SO_ERROR. Целое значение, возвращаемое функцией getsockopt, является кодом ошибки, требующей обработки. Затем значение переменной so_error сбрасывается ядром в 0 [128, с. 547].
Если процесс вызывает функцию read и возвращаемых данных нет, а значение so_error ненулевое, то функция read возвращает -1 с errno, которой присвоено значение переменной so_error [128, с. 516]. Это значение so_error затем сбрасывается в 0. Если в очереди для сокета есть данные, эти данные возвращаются функцией read вместо кода ошибки. Если значение so_error ненулевое, то при вызове процессом функции write возвращается -1 с errno, равной значению переменной so_error [128, с. 495], а значение so_error сбрасывается в 0.
ПРИМЕЧАНИЕ
В коде, показанном на с. 495 [128], есть ошибка: so_error не сбрасывается в 0. Она была выявлена в реализации BSD/OS. Всегда, когда для сокета возвращается ошибка, требующая обработки, so_error должна быть сброшена в 0.
Здесь вы впервые встречаетесь с параметром сокета, который можно получить, но нельзя установить.
Данный текст является ознакомительным фрагментом.
Читайте также
Параметр сокета IP_HRDINCL
Параметр сокета IP_HRDINCL
Если этот параметр задан для символьного сокета IP (см. главу 28), нам следует создать наш собственный заголовок IP для всех дейтаграмм, которые мы отправляем через символьный сокет. Обычно ядро создает заголовок IP для дейтаграмм, отправляемых через
Параметр сокета IP_OPTIONS
Параметр сокета IP_OPTIONS
Установка этого параметра позволяет нам задавать параметры IP в заголовке IPv4. Это требует точного знания формата параметров IP в заголовке IP. Мы рассмотрим этот параметр в контексте маршрутизации от отправителя IPv4 в разделе
Параметр сокета IP_RECVDSTADDR
Параметр сокета IP_RECVDSTADDR
Этот параметр сокета заставляет функцию recvmsg возвращать IP-адрес получателя в получаемой дейтаграмме UDP в качестве вспомогательных данных. Пример использования этого параметра мы приводим в разделе
Параметр сокета IP_RECVIF
Параметр сокета IP_RECVIF
Этот параметр сокета заставляет функцию recvmsg возвращать индекс интерфейса, на котором принимается дейтаграмма UDP, в качестве вспомогательных данных. Пример использования этого параметра мы приводим в разделе
Параметр сокета IP_TOS
Параметр сокета IP_TOS
Этот параметр позволяет нам устанавливать поле тип службы (тип сервиса) (TOS, type-of-service) (рис. А.1) в заголовке IP для сокета TCP или UDP. Если мы вызываем для этого сокета функцию getsockopt, возвращается текущее значение, которое будет помещено в поля DSCP и ECN
Параметр сокета IP_TTL
Параметр сокета IP_TTL
С помощью этого параметра мы можем устанавливать и получать заданное по умолчанию значение TTL (time-to-live field — поле времени жизни, рис. А.1), которое система будет использовать для данного сокета. (TTL для многоадресной передачи устанавливается при помощи
7.7. Параметр сокета ICMPv6
7.7. Параметр сокета ICMPv6
Единственный параметр сокета, обрабатываемый ICMPv6, имеет аргумент level, равный
Параметр сокета ICMP6_FILTER
Параметр сокета ICMP6_FILTER
Этот параметр позволяет нам получать и устанавливать структуру icmp6_filter, которая определяет, какие из 256 возможных типов сообщений ICMPv6 передаются для обработки на символьный сокет. Мы обсудим этот параметр в разделе
Параметр сокета IPV6_CHECKSUM
Параметр сокета IPV6_CHECKSUM
Этот параметр сокета задает байтовое смещение поля контрольной суммы внутри данных пользователя. Если значение неотрицательное, ядро, во-первых, вычисляет и хранит контрольную сумму для всех исходящих пакетов и, во-вторых, проверяет полученную
Параметр сокета IPV6_DONTFRAG
Параметр сокета IPV6_DONTFRAG
Установка этого параметра запрещает автоматическое включение заголовка фрагментации для UDP и символьных сокетов. При этом исходящие пакеты, размер которых превышает MTU исходящего интерфейса, просто сбрасываются. Системный вызов ошибку не
Параметр сокета IPV6_NEXTHOP
Параметр сокета IPV6_NEXTHOP
Этот параметр задает адрес следующего транзитного узла для дейтаграммы в виде структуры адреса сокета. Подробнее о нем рассказывается в разделе
Параметр сокета IPV6_PATHMTU
Параметр сокета IPV6_PATHMTU
Этот параметр может быть только получен, но не установлен. При его считывании система возвращает текущее значение маршрутной MTU, определенное соответствующим методом (см. раздел
Параметр сокета IPV6_RECVDSTOPTS
Параметр сокета IPV6_RECVDSTOPTS
Установка этого параметра означает, что любые полученные IPv6-параметры получателя должны быть возвращены в качестве вспомогательных данных функцией recvmsg. По умолчанию параметр отключен. Мы опишем функции, используемые для создания и обработки
Параметр сокета TCP_MAXSEG
Параметр сокета TCP_MAXSEG
Этот параметр сокета позволяет нам получать или устанавливать максимальный размер сегмента (maximum segment size, MSS) для соединения TCP. Возвращаемое значение — это количество данных, которые наш TCP будет отправлять на другой конец соединения. Часто это
Параметр сокета TCP_NODELAY
Параметр сокета TCP_NODELAY
Если этот параметр установлен, он отключает алгоритм Нагла (Nagle algorithm) (см. раздел 19.4 [111] и с. 858–859 [128]). По умолчанию этот алгоритм включен.Назначение алгоритма Нагла — сократить число небольших пакетов в глобальной сети. Согласно этому алгоритму,
Параметр сокета SCTP_ADAPTION_LAYER
Параметр сокета SCTP_ADAPTION_LAYER
При инициализации ассоциации любой собеседник может указать на наличие уровня-адаптора. Это указание должно представлять из себя 32-разрядное беззнаковое целое, которое может использоваться двумя приложениями для координации локального
I’m curious about the behavior of the SO_ERROR socket option used with getsockopt() after a successful socket operation
The Open Group specification:
SO_ERROR
Reports information about error status and clears it. This option shall store an int value.
Usually I see SO_ERROR used after a socket operation returns -1, but what happens if the previous socket operation succeeded (thus not returning -1). Does the getsockopt() call fail? Does it return 0 as the int value?
asked Apr 6, 2015 at 21:24
It’s ok for non-blocking connect, see connect(2)
The socket is nonblocking and the connection cannot be completed immediately. It is possible to select(2) or poll(2) for completion by selecting the socket for writing. After select(2) indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect() completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure).
other is undefined.
answered Apr 16, 2015 at 13:49
It’s undefined. You should only call this option when you already know that there has been an error. Not as a means to discover whether there was one.
answered Apr 6, 2015 at 22:15
I’ve learned more about SO_ERROR in Unix Networking Programmig Vol 1, it’s become clear to me. SO_ERROR is used to report asynchronous errors that are the result of events within the network stack and not synchronous errors that are the result of a library call (send/recv/connect). Synchronous results are reported via errno.
Calling getsockopt() with SO_ERROR after a library call returns -1 is incorrect from the POSIX implementation.
Learning of the non-blocking connect result via select is an example of discovering when the asynchronous result is ready (which can then be retrieved via SO_ERROR)
answered Sep 13, 2017 at 16:39
| Bug #31233 | Autoload Interceptor causing unexplained instability | |||
|---|---|---|---|---|
| Submitted: | 2004-12-21 22:59 UTC | Modified: | 2005-03-12 01:00 UTC | |
| From: | smclean at gmail dot com | Assigned: | ||
| Status: | No Feedback | Package: | Scripting Engine problem | |
| PHP Version: | 5.0.3 | OS: | Linux | |
| Private report: | No | CVE-ID: | None |
[2004-12-21 22:59 UTC] smclean at gmail dot com
Description:
------------
Under special circumstances the autoload interceptor seems to cause instability.
All instances of this crash I have been able to reproduce involve triggering the autoload interceptor by unserializing objects of undefined classes, with custom error handling configured. By either disabling the error handling, the autoload interceptor, or not unserializing the object, the crash is prevented. I titles this bug 'Autoload interceptor causing ...' because the crash always occurs within the autoload interceptor itself or soon after.
In the given example, the actual crash occurs when attempting to simply cast a GET variable to a bool and print it, but if you change the parameters of the test, the crash can occur in a multitude of other places, including within the autoload interceptor itself (this is the location of the crash when I originally discovered it, but the reproducing scripts I created caused it to crash elsewhere).
I attempted to generate a gdb backtrace, but unfortunately --enable-debug seemed to prevent the crash from occuring. I was able to duplicate this bug on three different Linux machines, each running php 5.0.3 on Slackware 10.
Reproduce code:
---------------
Download the following tarball:
http://pio.longstair.com/misc/crash.tgz
Execute:
tar zxvf crash.tgz
cd crash-2.0
php runme2.php
Explanation:
runme2.php loads custom error handling and an autoload interceptor include. It then attempts to unserialize a serialized undefined object, and print it out. This succeeds, but the environment becomes unstable, and a simple boolean cast segfaults it.
runme1.php simply generates the serialized object string used in runme2.php
Expected result:
----------------
Normal program termination
Actual result:
--------------
Segmentation Violation
GDB:
Program received signal SIGSEGV, Segmentation fault.
zend_error (type=2056, format=0x21fd3500 <Address 0x21fd3500 out of bounds>)
at /home/sean/instball/php-5.0.3/Zend/zend.c:985
985 if (Z_TYPE_P(retval) == IS_BOOL && Z_LVAL_P(retval) == 0) {
Patches
Add a Patch
Pull Requests
Add a Pull Request
History
AllCommentsChangesGit/SVN commitsRelated reports
[2005-03-12 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
Fixes are available
DB2 Version 9.5 Fix Pack 3b for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
APAR status
-
Closed as program error.
Error description
-
You may observe RUNSTATS with distribution statistics running slow on Sun UltraSPARC III, IIIi, III+, and IV systems. The problem is related to floating point conversion operations done in the algorithm that collects distribution statistics. It is typically observable in tables with a large number of rows, for example 10 million rows. In a DPF (Database Partitioning Feature) environment, RUNSTATS executes on just one database partition, and it is the number of rows on that database partition that is of consideration.
Local fix
-
Use table sampling to reduce the number of rows processed by RUNSTATS. Reduce the number of columns for which to collect distribution statistics, for example, skipping columns with uniformly distributed data and/or columns that do not appear frequently in equality or range predicates.
Problem summary
-
You may observe RUNSTATS with distribution statistics running slow on Sun UltraSPARC III, IIIi, III+, and IV systems. The problem is related to floating point conversion operations done in the algorithm that collects distribution statistics. It is typically observable in tables with a large number of rows, for example 10 million rows. In a DPF (Database Partitioning Feature) environment, RUNSTATS executes on just one database partition, and it is the number of rows on that database partition that is of consideration
Problem conclusion
-
First Fixed in DB2 UDB Version 9.5, FixPak 3
Temporary fix
-
Use table sampling to reduce the number of rows processed by RUNSTATS. Reduce the number of columns for which to collect distribution statistics, for example, skipping columns with uniformly distributed data and/or columns that do not appear frequently in equality or range predicates
Comments
APAR Information
-
APAR number
IZ31233
-
Reported component name
DB2 EDE SOLARIS
-
Reported component ID
5724N7602
-
Reported release
950
-
Status
CLOSED PER
-
PE
NoPE
-
HIPER
NoHIPER
-
Special Attention
NoSpecatt
-
Submitted date
2008-09-04
-
Closed date
2009-04-16
-
Last modified date
2009-04-16
-
APAR is sysrouted FROM one or more of the following:
IZ31182
-
APAR is sysrouted TO one or more of the following:
Fix information
-
Fixed component name
DB2 EDE SOLARIS
-
Fixed component ID
5724N7602
Applicable component levels
-
R950 PSY
UP
[{«Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»},»Business Unit»:{«code»:»BU058″,»label»:»IBM Infrastructure w/TPS»},»Product»:{«code»:»SSEPGG»,»label»:»DB2 for Linux- UNIX and Windows»},»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Version»:»950″}]
Document Information
Modified date:
04 October 2021
Bug 31233
— jsp compile errors with Chinese Characters
Summary:
jsp compile errors with Chinese Characters
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
Note |
#31233
closed
Cleanup/optimization
(fixed)
| Reported by: | Owned by: | Jon Dufresne | |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Change History (9)
| Triage Stage: |
Unreviewed → Accepted |
|---|
| Owner: | changed from nobody to Jon Dufresne |
|---|---|
| Status: |
new → assigned |
| Triage Stage: |
Accepted → Ready for checkin |
| Resolution: | → fixed |
|---|---|
| Status: |
assigned → closed |
Note: See
TracTickets for help on using
tickets.