Ошибка xmlsax2characters out of memory

Here is the sad truth. There are two basic ways of working with XML, DOM-based, where the whole XML file is present in memory at once (with considerable overhead to make it fast to traverse), and SAX based where the file goes through memory, but only a small portion of it is present at any given time.

However, with DOM, large memory consumption is pretty much normal.

Now XSLT language in general allows constructions that access any parts of the whole file at any time and it therefore requires the DOM style. Some programming languages have libraries that allow feeding SAX input into an XSLT processor, but this necessarily implies restrictions on the XSLT language or memory consumption not much better than that of DOM. PHP does not have a way of making XSLT read SAX input, though.

That leaves us with alternatives to DOM; there is one, and is called SimpleXML. SimpleXML is is a little tricky to use if your document has namespaces. An ancient benchmark seems to indicate that it is somewhat faster, and probably also less wasteful with memory consumption, than DOM on large files.

And finally, I was in your shoes once in another programming language. The solution was to split the document into small ones based on simple rules. Each small document contained a header copied from the whole document, one «detail» element and a footer, making its format valid against the big XML file’s schema. It was processed using XSLT (assuming that processing of one detail element does not look into any other detail element) and the outputs combined. This works like charm but it is not implemented in seconds.

So, here are your options. Choose one.

• Parse and process XML using SAX.
• Use SimpleXML and hope that it will allow slightly larger files within the same memory.
• Execute an external XSLT processor and hope that it will allow slightly larger files within the same memory.
• Split and merge XML using this method and apply XSLT on small chunks only. This method is only practical with some schemas.

modern libxml2 versions

This does not appear to be an issue with libxml 2.9.x. For a file that’s 14M in size:

> Nokogiri::XML.parse(File.open("large.xml")).root.children.first.text.length
 => 9999894 
> puts Nokogiri::XML.parse(File.open("large.xml")).errors
xmlSAX2Characters: huge text node
Extra content at the end of the document

but notice that the HUGE config option allows us to parse the whole thing:

> Nokogiri::XML.parse(File.open("large.xml")) {|c| c.huge}.root.children.first.text.length
 => 14065665
> puts Nokogiri::XML.parse(File.open("large.xml")) {|c| c.huge}.errors
 => nil 

older libxml2 versions

The problem originally reported was with much older versions of libxml2; e.g. 2.7.3.

Compiling Nokogiri v1.7.0.1 against libxml 2.7.3:

# Nokogiri (1.7.0.1)
    ---
    warnings: []
    nokogiri: 1.7.0.1
    ruby:
      version: 2.4.0
      platform: x86_64-linux
      description: ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]
      engine: ruby
    libxml:
      binding: extension
      source: packaged
      libxml2_path: "/home/flavorjones/code/oss/nokogiri/ports/x86_64-pc-linux-gnu/libxml2/2.7.3"
      libxslt_path: "/home/flavorjones/code/oss/nokogiri/ports/x86_64-pc-linux-gnu/libxslt/1.1.20"
      libxml2_patches: []
      libxslt_patches: []
      compiled: 2.7.3
      loaded: 2.7.3

results in a segfault when parsing a large file; but the segfault can be avoided by setting the HUGE option (as above).

conclusion

Unfortunately, there’s nothing I can think of to prevent old, buggy versions of libxml2 from crashing in this case; the bug is completely internal to libxml2.

As a workaround, consider using the HUGE option; or consider using the vendored version of libxml2; or consider upgrading your system’s libxml2 version.

Apologies it took so long to close this out.

Вот грустная правда. Существует два основных способа работы с XML, основанный на DOM, где весь XML файл присутствует в памяти сразу (со значительными накладными расходами, чтобы ускорить его перемещение) и SAX, на котором файл проходит через память, но только небольшая его часть присутствует в любой момент времени.

Однако с DOM большое потребление памяти в значительной степени нормальное.

В настоящее время язык XSLT в общем позволяет создавать конструкции, которые в любой момент могут обращаться к любым частям всего файла и поэтому требует стиля DOM. Некоторые языки программирования имеют библиотеки, которые позволяют подавать вход SAX в XSLT-процессор, но это обязательно подразумевает ограничения на использование языка XSLT или памяти не намного лучше, чем у DOM. PHP не имеет способа сделать XSLT-чтение SAX-входа, однако.

Это оставляет нам альтернативы DOM; есть один и называется SimpleXML. SimpleXML немного сложно использовать, если ваш документ имеет пространства имен. Древний бенчмарк, кажется, указывает на то, что он несколько быстрее и, вероятно, также менее расточительно с потреблением памяти, чем DOM на больших файлах.

И, наконец, я был на вашем месте один раз на другом языке программирования. Решение заключалось в том, чтобы разделить документ на небольшие, основанные на простых правилах. Каждый маленький документ содержал заголовок, скопированный из всего документа, один элемент «detail» и нижний колонтитул, делая его формат действительным для большой схемы XML файла. Он обрабатывался с использованием XSLT (при условии, что обработка одного элемента детали не рассматривается в каком-либо другом детальном элементе), а выходы объединены. Это работает как шарм, но не выполняется в секундах.

Итак, вот ваши варианты. Выберите один.

• Разбирайте и обрабатывайте XML с помощью SAX.
• Используйте SimpleXML и надеемся, что он позволит немного увеличить файлы в одной и той же памяти.
• Выполните внешний XSLT-процессор и надейтесь, что он позволит немного увеличить файлы в одной и той же памяти.
• Разделить и объединить XML, используя этот метод и применить XSLT только к небольшим фрагментам. Этот метод применим только с некоторыми схемами.

IamAlexy

08.03.09 — 21:26

ТелепатБот

1 — 08.03.09 — 21:26

Злопчинский

2 — 08.03.09 — 21:35

гаечки поштучно учитываете?

IamAlexy

3 — 08.03.09 — 21:36

Aleksey_3

4 — 08.03.09 — 21:48

Только бить, и выгружать частями

IamAlexy

5 — 08.03.09 — 21:50

(4) угу. просто хотел уточнить.. а то потрачу время а окажется что есть какойнить «обновленный драйвер для xml» который позволяет работать с файлами больше чем 1 гиг.

Cap_1977

6 — 08.03.09 — 21:50

(0) У тебя валиться XML-парсер, тот который от мелкософта. Валиться он изза того что пытается отожрать больше 2 Гб памяти (он _весь_ формируемый/считывамый xml-файл держит в памяти + его собственные глюки). Попробуй формировать выходной файл вручную — xml этоже по сути текст ))).

milan

7 — 08.03.09 — 21:54

(6) Скорее всего не удастся выгрузить в последовательный файл, хотя чем черт не шутит.

IamAlexy

8 — 08.03.09 — 22:01

(7) даже не буду пытаться.
либо по оле выгружу либо правила покоцаю чтобы частями выгружать.. подумаю еще что именно делать…

milan

9 — 08.03.09 — 22:04

(8) Не по спортивному получается

ДенисЧ

10 — 08.03.09 — 22:10

IamAlexy

11 — 08.03.09 — 22:12

(10) быстрее по оле + лицензии на х64 сервер предприятия нету
а система и так х64

milan

12 — 08.03.09 — 22:15

(11) Сдается мне что по ОЛЕ не быстро 600К контрагентов с остатками выгрузится

IamAlexy

13 — 08.03.09 — 22:18

milan

14 — 08.03.09 — 22:21

IamAlexy

15 — 08.03.09 — 22:22

(14) на 80% готовая.
а зачем по оле бить на части?

milan

16 — 08.03.09 — 22:25

(15)
>>на четырехядерном проце можно запустить четыре потока и они будут нормально в полную силу выгружаться
Или 4 раза одно и тоже выгружать ???

Cap_1977

17 — 08.03.09 — 22:26

(13) «1с не занимает все ядра в процессе работы.» — правильно, семерка писалась когда о гипертрейдинге и двухголовости еще не слыхали.
«тоесть на четырехядерном проце можно запустить четыре потока и они будут нормально в полную силу выгружаться :)» — издешь ))) будкт использваться только один камень.

IamAlexy

18 — 08.03.09 — 22:27

(17) хм. нужно думаешь разные процессы всеравно на первый будут вешаться ?

IamAlexy

19 — 08.03.09 — 22:29

Cap_1977

20 — 08.03.09 — 22:32

(18) Да. всегда грузиться первый камень. Хочешь чтоб нагрузка распределялась на все: ставь линь (или бсд) поверх нее wmware esx server. на него гостевую вынь 2003; тогда у тебя будут загружены _все_ камни — nix разрулит.

milan

21 — 08.03.09 — 22:35

IamAlexy

22 — 08.03.09 — 22:36

(20) Set Affinity в таск менеджере решает данную проблему без линуха,бсд и вмваре

milan

23 — 08.03.09 — 22:37

(22) Опять не по спортивному, а так поставил в вмваре линух, там в виртуалбох вин2003 а там и 1с запустил — благодать

IamAlexy

24 — 08.03.09 — 22:38

(23) тучные, потные, ленивые программисты 1с с отдышкой и пивом далеки от спорта…

Cap_1977

25 — 08.03.09 — 22:49

(21) Предложенная схема была реализована в Казани, фирмы Прогресс, база РарусАльфаАвто, никак не оптимизированная, только доточенная, юзеров онлайн сидело 60+. железка была «супермикро», 4 гига оперативы, 4 камня. Тянула еще второй DC.

milan

26 — 08.03.09 — 23:08

(25) Что-то я не понимаю смысл огорода. Один процесс 1С никакой вмваре или линух на несколько потоков никак не разложат. Поднимать линух, на нем вин2003 … непонятно.

IamAlexy

27 — 08.03.09 — 23:10

(26) там было поднято три вмваре.
каждому вмваре по ядру
в каждом вмваре по 20 пользователей

Cap_1977

28 — 08.03.09 — 23:10

(26) Смысл огорода в том, что поднимая линух и ставя на него гостевую внь ты уходишь от того что один процесс 1С исполняется на одном камне; линь раскидывает нагрузку по всем процам.

Aleksey_3

29 — 08.03.09 — 23:12

(27,28) А смысл? Каждый юзер юзает свой процесс 1С. А ОС сама эти процессы раскидывет по ядрам. Поэтому смысл ставить на тормознутую вирт. машину?

Cap_1977

30 — 08.03.09 — 23:14

(27) думмаю что так настроить было можно ))) но как то архисложно получается )))
(29) юзать то он зюзает. ыопросов нет. о только терминал на винде, в котором сидят пользователи, упорно грузит один камень.

Aleksey_3

31 — 08.03.09 — 23:15

Ну у меня отдельная машина под 1С и отдельная под терминал, и там и там юзаются все ядра, без извращений. На филиале все во одном, и тоже не замечал, чтобы ядра простаивали.

Cap_1977

32 — 08.03.09 — 23:19

(31) Установил 2003. Роль назначил: сервер терминалов. Настроил юзерам коннекты к серверу. Установил на серваке 1С. Базы положил локально. Пользователи заходят в 1С, работают. ДЗ выдает загрузку 1-го камня. Что я делаю не так ?

Aleksey_3

33 — 08.03.09 — 23:24

2003 какой чистый или R2? Сколько юзеров? А если в ручную назначить 1С у юзера другой камень?

milan

34 — 08.03.09 — 23:28

(32) Что-то делаешь не так, не нужно ставить сервер терминалов, чтобы разные процессы 1с грузили разные ядра. Запусти на локальной машине две одинески и будешь приятно удивлен.
Может что-то там с лицензиями в вин2003 ???

Aleksey_3

35 — 08.03.09 — 23:34

(32) Так чисто, чтобы мы понимали о чем речь. 1С у 1 юзера под виндоус не может занимать N ядер. 1С однаядерная, т.е. 1 экземпляр = 1 ядро. Но ОС может раскидывать разные экземпляры 1С на разные ядра, т.е. каждый экземпляр 1С будет занимать свое отдельное ядро (в общем случае).

milan

36 — 08.03.09 — 23:40

(35) В общем случае не обязательно «Каждый экземпляр 1С будет занимать свое отдельное ядро», разложит как посчитает нужным, и не факт что несколько 1с на первом ядре это плохо. На самом деле 1С довольно слабо грузит проц, в основном грузится дисковая подсистема за счет всяких временных ДБФов и прочей ахинеи.

Cap_1977

37 — 08.03.09 — 23:41

никс раскидывает задачи одного юзера на несколько камней.

milan

38 — 08.03.09 — 23:44

(37) Ты утверждаешь, что однопоточный процесс никс раскладывает на несколько ядер ???

Aleksey_3

39 — 08.03.09 — 23:47

(37) При этом тормоза вирт машины сводят этот плюс на нет.
Если бы у тебя было бы 20 камней и 4 юзера, тогда да. Но у тебя и так на каждом камни сидит по 5 юзеров, поэтому смысл раскидывать на то, что уже занято?

Cap_1977

40 — 08.03.09 — 23:51

(38) таг. в (25) мну указал что твориться если поставить никс. В (32) я задал вопрос. В (37) — вывод. Неявный вывод, но все таки.
1. Где утверждкние ?
2. Смысл ловить меня за язык ? Не работает так как как утверждаю в 25 — я мутаг. Готов сменить картинку в профиле.
3. Что мешает тебе попробывать а не молоть языком ?

IamAlexy

41 — 08.03.09 — 23:55

лучше бы придумали где взять волшебный_патч_заставляющий_виндовых_xml_понимать_файлы_больше_2GB

Cap_1977

42 — 09.03.09 — 00:05

(41) звонить в_подддержку_не пользоваться_вынью_взять_в_руки_фзыкпрограммирования. Быть, а не казаться.

IamAlexy

43 — 09.03.09 — 00:12

(42) см (24)

Cap_1977

44 — 09.03.09 — 00:17

milan

45 — 09.03.09 — 00:32

(40) Человеку свойственно ошибаться, как в 25 проверять не стану, ибо лень. Да и никаких рекомендаций от 1с в эту сторону нет. Опять же проверять что вин2003 работает производительнее под вмварью из под никса не хочется.
а то что такая система будет работать я не сомневаюсь.
К тому же тут другая задача.
(41) переписывай под сакс модель выгрузку от 1С тогда будет ограничение только на размер файла на ФС

Cap_1977

46 — 09.03.09 — 00:34

(45) благодарю

romix

Модератор

48 — 09.03.09 — 04:05

НП

49 — 09.03.09 — 08:26

(0) Перегружать справочники лучше при помощи COM-соединения. Размер программы -операторов 15-20 плюс по оператору на каждый реквизит справочника. Запускется в режиме транзакций с периодическим завершением и началом транзакции через 200-300 элементов справочника.

dk

50 — 09.03.09 — 08:53

хм, а 64-битного парсера хмл мелкомягкие не выпустили?

хм… у меня такая ошибка была не в 1с а просто когда открываешь файл… после перезапуска исчезает.. оказался банально вирус… он перехватывал запрос проги на достаточность памяти и посылал неверный ответ в следствии чего прогама сама по се вылетала!

<?php 
/** задача: вывести список доступных id с количеством подэлементов */
$io = false; // интуитивный переключатель прохода
$count = 0; // кол-во load'ов в over'е
$id = ''; // текущий id
$cache = @fopen('cache.txt', 'x'); // работа с кешем
if (!$cache) die ('cache exists!');
/** strread (буфер, io, счётчик, id, поток кеша) */
function strread ($buffer, &$v2, &$v3, &$v4, &$v5)
{
	if (!$v2) // ищем проход
	{
		if (strpos($buffer, '<over') === false)
		{
			$v2 = false;
		}
		else
		{
			$v4 = str_replace(array('<over id="', '">', '" />'), '', $buffer);
			/** можно и preg_match, но в данном случае 
			 * мы знаем что другого быть не может, 
			 * поэтому экономим память…
			 */
			$v2 = true;
		}
	}
	else // ищем выход из over
	{
		if (strpos($buffer, '</over>') === false)
		{
			$v3++;
			$v2 = true;
		}
		else
		{
			fwrite($v5, "id: $v4, loads: $v3rn");
			$v3 = 0; $v4 = ''; // обнуляем переменные
			$v2 = false;
		}
	}
}
$xml = fopen('big.xml', 'rtb'); //открыли файл
while (!feof($xml)) strread(trim(fgets($xml)), $io, $count, $id, $cache);
fclose($xml); fclose($cache); // закрываем потоки xml и cache

<ixxxxxi>
	<data>nodata</data>
	<over id="Anzhxicfq">
		<load>like</load>
			<offload>21</offload>
			<offload>15</offload>
		<load>like</load>
		<load>like</load>
	</over>
	<over id="ASy8d0nas">
		<load>like</load>
		<load>like</load>
		<load>like</load>
	</over>
	<over id="ASnax9z9u">
		<load>like</load>
		<load>like</load>
		<load>like</load>
	</over>
	<over id="Vefu9a1AA">
		<load>like</load>
		<load>like</load>
	</over>
	<over id="NAsu9ddda" />
	<over id="Zadli1110">
		<load>like</load>
		<load>like</load>
		<load>like</load>
	</over>
</ixxxxxi>

Вот печальная правда. Существует два основных способа работы с XML: на основе DOM, когда весь XML-файл одновременно находится в памяти (со значительными накладными расходами, чтобы ускорить его перемещение), и на основе SAX, когда файл проходит через память, но только небольшая его часть присутствует в любой момент времени.

Однако в DOM потребление большого объема памяти вполне нормально.

Теперь язык XSLT в целом допускает конструкции, которые в любое время обращаются к любым частям всего файла, и поэтому для него требуется стиль DOM. Некоторые языки программирования имеют библиотеки, которые позволяют подавать входные данные SAX в процессор XSLT, но это обязательно подразумевает ограничения на язык XSLT или потребление памяти, не намного лучше, чем у DOM. PHP нет пути Однако заставить XSLT читать ввод SAX.

Это оставляет нам альтернативы DOM; есть один, и он называется SimpleXML. SimpleXML немного хитрый использовать, если в вашем документе есть пространства имен. Древний эталон кажется, указывает на то, что он несколько быстрее и, вероятно, также менее расточительно с потреблением памяти, чем DOM на больших файлах.

И, наконец, я был на вашем месте однажды на другом языке программирования. Решение состояло в том, чтобы разбить документ на маленькие на основе простых правил. Каждый небольшой документ содержал заголовок, скопированный из всего документа, один элемент «detail» и нижний колонтитул, что делало его формат допустимым для схемы большого XML-файла. Он был обработан с использованием XSLT (при условии, что при обработке одного элемента сведений не учитывается какой-либо другой элемент сведений), и выходные данные были объединены. Это работает как шарм, но не реализуется за секунды.

Итак, вот ваши варианты. Выбери один.

• Разбирать и обрабатывать XML с помощью SAX.
• Используйте SimpleXML и надеюсь, что это позволит хранить файлы немного большего размера в той же памяти.
• Запустите внешний XSLT-процессор и надейтесь, что он позволит размещать файлы чуть большего размера в той же памяти.
• Разделите и объедините XML, используя Этот метод и применяйте XSLT только к небольшим фрагментам. Этот метод применим только для некоторых схем.

Description:
------------
Since version 2.7.3 libxml limits the maximum size of a single text node to 10MB.
The limit can be removed with a new option, XML_PARSE_HUGE.
PHP has no way to specify this option to libxml.

I found the bug when making af SOAP-request where the reply contained a 20MB string.
SoapClient->__call() threw an exception: 'looks like we got no XML document'

Using libxml_use_internal_errors(true) and libxml_get_errors() I could narrow it down to a LibXMLError, code 5, 'Extra content at the end of the document' - but the specified line and column was in the middle of a large text node.

Using SoapClient->__getLastResponse() I saved the response to a file.
The xmllib program xmllint then revealed the cause:
> xmllint --noout soap_response.txt 
soap_response.txt:111834: error: xmlSAX2Characters: huge text node: out of memory

We need a way to specify the XML_PARSE_HUGE option to libxml - perhaps something like a new function: libxml_parse_huge(true).


Reproduce code:
---------------
<?php
$xml = "<?xml version='1.0' encoding='utf-8' standalone='yes' ?><test>" . str_repeat('A', 12000000) . "</test>";
file_put_contents('file.xml', $xml);
$sxe = simplexml_load_file('file.xml');
if ($sxe instanceof SimpleXMLElement) {
	echo 'OKn';
}
else {
	var_dump($sxe);
}


Expected result:
----------------
OK

Actual result:
--------------
PHP Warning:  simplexml_load_file(): file.xml:1: error: xmlSAX2Characters: huge text node: out of memory in /usr/dana/data/developers/holst/mobilmap/cron/xml.php on line 5
PHP Warning:  simplexml_load_file(): AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA in /usr/dana/data/developers/holst/mobilmap/cron/xml.php on line 5
PHP Warning:  simplexml_load_file():                                                                                ^ in /usr/dana/data/developers/holst/mobilmap/cron/xml.php on line 5
bool(false)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports

I guess we could expose the constant value from ext/libxml if available like:
Index: libxml.c
===================================================================
--- libxml.c	(revision 288659)
+++ libxml.c	(working copy)
@@ -622,6 +622,9 @@
 	REGISTER_LONG_CONSTANT("LIBXML_COMPACT",	XML_PARSE_COMPACT,		CONST_CS | CONST_PERSISTENT);
 	REGISTER_LONG_CONSTANT("LIBXML_NOXMLDECL",	XML_SAVE_NO_DECL,		CONST_CS | CONST_PERSISTENT);
 #endif
+#if LIBXML_VERSION >= 20703
+	REGISTER_LONG_CONSTANT("LIBXML_PARSEHUGE",	XML_PARSE_HUGE,			CONST_CS | CONST_PERSISTENT);
+#endif
 	REGISTER_LONG_CONSTANT("LIBXML_NOEMPTYTAG",	LIBXML_SAVE_NOEMPTYTAG,	CONST_CS | CONST_PERSISTENT);
 
 	/* Error levels */


Does this work for you when passing it to SimpleXML's $option parameter?

(Patch made against PHP_5_3, but is just a 3 line c/p to other branches)

Hi Kalle.

Thanks for replying so soon.

Your patch does fix the issue when loading directly with 
simplexml_load_file('file.xml', 'SimpleXMLElement', LIBXML_PARSEHUGE);

However the error was not originally encountered using simplexml, but using SoapClient - and there does not seem to be a way to pass libxml-options to SoapClient.

So as far as I can tell, the problem remains when using SoapClient.

/Thing

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

"Added LIBXML_PARSEHUGE constant to overrides the maximum text size of a single text node when using libxml2.7.3+."

For everyone who came across this bug and is not using SimpleXML directly but SoapClient, you can switch to Zend Soap Component:

(standalone)
https://github.com/zendframework/zend-soap