Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug/Feature in Unix.open_process_full #2447

Closed
vicuna opened this issue May 11, 2000 · 2 comments
Closed

Bug/Feature in Unix.open_process_full #2447

vicuna opened this issue May 11, 2000 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented May 11, 2000

Original bug ID: 108
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hello,
I have a problem with the Unix.open_process_full function.
It crashes with a nasty exception:
uncaught exception Failure("equal: abstract value")
on my test program.

I've written a program that recreates the error, it is attached. The
program forks a simple process called myecho. "myecho" reads input
from stdin, and prints it out to stdout, and stderr after one
second. The source program "t.ml" writes the string "1234567812345678"
on its stdout (which is myecho's stdin) and waits. When the output
comes back, it performs the same action. The second iteration fails.
I think the problem is due to the fact that "t.ml" closes the channel
through which it communicates with "myecho" prior to the call to
Unix.close_process_full.

This kind of functionality (closing the channel prior to performing
Unix.close_process_full) is required in many programs. For example,
PGP uses this kind of call sequence.

Ohad.

�‹��ÜÒ�9��echo.tar�íXmoÛ6�î×èW\µ�°»Ø³›ÄÞìº@1´ë€m-šm�–u‚,Q6�Z�(‹?þøÝ�I[ö��[Ú �|0d‰¼7�´Z‹l©û+õàÓÑ8�ŒNO� �óñ“!þ#?Fî�i8Æûñp0:;�?Fcä�ž?��Àà�ú´¡¦¶©�x ?ÎÅòv¾j™ß‡;÷MJXH���ÝÖxkDš'J–�:]�YâÔÏ¥¼î×Jˆ
†S|®Œ,mR[ü[@m#º±U³�²¹0�â�_�þkSƒÕ¨·ÒÆÆÄÝéâ� ú¯W� ûiKŸé�õ?>��|ýŸŽÏÆ�â?���õ��Ôy|'êF?ÇðæÛ7�Ä +L‘f‚J�GÀÍ=oì�ë��¿-E ¿ÊT�Ã�©¹„Wé:�å1œùõØó¾^¦ù�žç¹È!Ó+Ä“ÔJ]¢j°K�ó4»\�Ý”9x�G/å5
ÄÕ¢BÜ1i¹�½l™š4C‡b¨×enôJìˆ8�uS�"A¡
ä²(„�¥…+aj´Zƒ.¶ë¸c?t…‹�C YDw×Æ@­³Ka�›Î•@Ì
•ÖK;Wý ÁÛ
�·y”¬-Ãz��ï"žIó<¡Yf?Âá�Ð?“»ê��áv[ãdæ&&�xØ�w�ŒXé+Ѳ±cÁÍþÝÈ
&¾Çÿ~!Ë<I•‚NєأzÏðòô�óvo°^�%2�к‚(›n��ª’õ2±rEas“_ô¡Ã�n!,Mè"O×Ø£º®ù¹õdÀê¼ ·/žPÇÉ15P×"ÙðŽG�sú±�«�·&‰Ùé×CñÁ%E.7ÙËÖ–ÒâoØ�¯�?×wÓÝHL7.–úÏàßÞ�ƒ�Y0ÓÓ?èX
X^s§=Üë�/Y”šƒè?¹{ró�b
Îu-|ÖvzC?®ô�88èñÃÀôl6ðÎú�LÁ+Û=¤tjø�âß˸��
oP�Ã�£éÉMšžü#M‘]W‚@oå’ë=¼ s�a?cæ±·¢Rë?1Ž9Ù�åU’�ƒÛ:ƒ‹÷tÄŠß<ÿéÕ,þ#l<r�?¡¹÷��¶?šTFg¢®![åè(b/Ì|îË�á�‘�?xî�?tt�’ŠÀ-ˆ'EƒeJ:¶�q’íž�½*ghJ�Î�Æ-ÁñÍ�Ÿ�]]æ¢ÎL¢‹D– Í•By¯ºÇ$|;—wÕ³ù•„…„I ¿�­ÔÃb.æÍb�Ž��Úe®VÜG¬ÕxÃ�w§>Nj�²mÜHs�™mªqÞP²œs��\�é��ŠÑšu�
”Ø�š•±S¤d��¯�Y�vIƒÝ-,ì{\sê��?ª'(0{”Ç
™øÔ?z)LbgЗT':ú�”O££bc;Óe–Zˆcè0¬�q��U·ëõu!hV„æAªnæ~
dœ[ˆb¾?%.ä�¦#nc!�붸xƒ���ü°3�—ݶGáÜé�¡�Jme±Þ¯„Ûã ?êx˽É�LC2Aiæn(ÙN0¶·T?7†žz��²P—pi5ØfÕ¥TŠE9µ\€0·M?˜�T�¸UáñH.Jm„¯�Wt»¥K>ò��­�\ U�1ÂHÂ/t1„Uµz2[mûæ{Ð~ílµt7žr?Ç?c'ý�t��Ö.‰ÜuÏ�Cˆ�‡PÿK_œ�Ï�l;¬­)wüËêÇimsÚû„>º€�ׄ�UBþð6î%"9šÑ�˜��=?‹Â÷üÐ�2%ð-†Ö}„Áä§Yˆft��+?êRDGBa?j�wÎé„Ìb¼ˆWü](f�£?pf¥³÷Û´Ìõ Ubi¢'f…Gºõ1H,À¥nT�s×�ñ�Ž§sDé>\¼~û. ¡ãï�èÞs³èW©©Å�Ç îù¶��óÔw¥å�–��?5™Iì�ñ/ü$í�ËèJ¨�åß¹tHˆY\£/�\=?ûÉMh¬´ ùãi�>{�hñ'š£×†›� ¶ô��Ôûãá““Ó³Ñø«ð�»Rn¥Bk¯Áo,m�9U¤R1,Æßp?0A±¹ff]Ùسòîq6q��dú�9itöôQý }â‡)�ª©—ô‰�#ŒX¾Ÿ?-GŽ>äÇV6vÌ{ž8€�þ,¼?�ž}/6퇅ñÕÂån�=o2Š.J�VÎá­Oä ½$fÚ�:‚ç‚#„Ë�Îêé¶ÂøàzÒ�ÐÐÝ“û�ü%ë‡ôRP£ý”6>ôýw¼ùþs2�?�éû/ÖÉáûÏ}Pÿüç—/¿ûõÅù�ú+ìÿxYÓEÒ�úÙJÓEÒå:Â!�™DG:KW*ƒÞ�z�|þÔÏ\‡�]Ùí„$�-��?>»[Ñ1E�}�˜€�×®ð5ŠžØë]�q—±óô�â�Ÿ2%çÐS
‚74|�Z¥A,rªP?»¡Ñ–ï�Eží6m[aTI?µœ K�E�xŒÃ�Z^¿�û±âð¿ÅŸ��è@�:Ð?�t ��è@�:ÐýÐ_ç�=`�(��----------------

@vicuna
Copy link
Author

vicuna commented May 16, 2000

Comment author: administrator

I have a problem with the Unix.open_process_full function.
It crashes with a nasty exception:
uncaught exception Failure("equal: abstract value")
on my test program.

I've written a program that recreates the error, it is attached.

Thanks, I had no problems reproducing the crash.

It turns out to be an absurdity in the implementation of Unix.open_process*
and Unix.close_process*. Namely, to keep track of which processes are
attached to which channels, the Unix module uses an hash table indexed
by I/O channels. This is totally bogus since (in OCaml 2.04 and 3.00
at least), equality on channels is unreliable and raises
Failure("equal: abstract value") unless the two channel objects are
physically equal. Any program that has several processes created with
Unix.open_process* active at the same time may cause the Failure
exception.

Fortunately, OCaml 3.00 makes it very easy to attach a meaningful
equality function to I/O channels. This is what the patch below does,
and with it your test program works fine.

This kind of functionality (closing the channel prior to performing
Unix.close_process_full) is required in many programs. For example,
PGP uses this kind of call sequence.

OK. This doesn't seem to cause any problems, since it is legal to
close an I/O channel several times.

Thanks for the bug report.

Best regards,

  • Xavier Leroy

Index: csl/byterun/io.c
diff -u csl/byterun/io.c:1.41 csl/byterun/io.c:1.42
--- csl/byterun/io.c:1.41 Mon Apr 17 22:01:34 2000
+++ csl/byterun/io.c Tue May 16 11:11:51 2000
@@ -10,7 +10,7 @@
/* */
/***********************************************************************/

-/* $Id: io.c,v 1.41 2000/04/17 20:01:34 doligez Exp $ /
+/
$Id: io.c,v 1.42 2000/05/16 09:11:51 xleroy Exp $ */

/* Buffered input/output. */

@@ -376,10 +376,17 @@
stat_free(chan);
}

+static int compare_channel(value vchan1, value vchan2)
+{

  • struct channel * chan1 = Channel(vchan1);
  • struct channel * chan2 = Channel(vchan2);
  • return (chan1 == chan2) ? 0 : (chan1 < chan2) ? -1 : 1;
    +}

static struct custom_operations channel_operations = {
"_chan",
finalize_channel,

  • custom_compare_default,
  • compare_channel,
    custom_hash_default,
    custom_serialize_default,
    custom_deserialize_default

@vicuna
Copy link
Author

vicuna commented May 16, 2000

Comment author: administrator

Fixed on 2000-05-16 by Xavier (added proper comparison function to I/O
channels).

@vicuna vicuna closed this as completed May 16, 2000
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant