From quentusrex@REDACTED Thu Dec 2 06:01:48 2010 From: quentusrex@REDACTED (William King) Date: Wed, 01 Dec 2010 21:01:48 -0800 Subject: Located a segfault in erlang:port_control Message-ID: <4CF7283C.10401@gmail.com> While testing the erlang bindings for OpenCL I ran into the segfault. I decided to follow this trail rather than changing anything. Any ideas? I've tried: ERL_CRASH_DUMP=crash.dump erl But that does not result in a crash dump. Here is the line of code that I've tracked it to: call(Code, Args) -> io:format("Still alive2.5 Port: ~p Code: ~p Args ~p \n", [?CL_PORT, Code, Args]), Reply = erlang:port_control(?CL_PORT, Code, Args), io:format("Still alive3 \n"), case decode(Reply) of {event,Ref} -> wait_reply(Ref); Result -> Result end. Here is the output before the segfault: quentusrex@REDACTED:~/git/quentustech/erlang/cl/examples$ ERL_CRASH_DUMP=dump.dump erl Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:6:6] [rq:6] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.1 (abort with ^G) 1> cl_mul:test(). cl_drv: WARNING: missing +A option (async driver calls!) Still alive2.5 Port: ecl_port Code: 2 Args <<>> Still alive3 Still alive2.5 Port: ecl_port Code: 3 Args <<224,254,113,1,0,0,0,0,255,255,255, 255>> Still alive3 Still alive2.5 Port: ecl_port Code: 6 Args <<2,0,0,0,0,0,0,0,160,255,113,1,0,0, 0,0,16,0,114,1,0,0,0,0>> Still alive3 platform created build: /home/quentusrex/erlang/cl/examples/mul4x4.cl File opened Still alive2.5 Port: ecl_port Code: 38 Args [<<160,153,113,1,0,0,0,0>>, <<"//\n// Multiply count 4x4 matrices with a constant matrix\n//\n\n__kernel void mul4x4(__global float* input,\n\t\t __global float* output,\n\t\t const float16 a,\n\t\t const unsigned int count)\n{\n int ix;\n __global float* b;\n __global float* c;\n \n ix = get_global_id(0);\n if (ix < count) {\n int i,j,k;\n\n\tb = input + ix*16;\n\tc = output + ix*16;\n\n\tfor (i=0; i<4; i++) {\n\t for (j=0; j<4; j++) {\n\t float s1 = 0.0;\n\t\tfor (k=0; k<4; k++) {\n\t\t float t1 = a.s(4*i+k);\n\t\t float t2 = b[4*k+j];\n\t\t s1 += (t1*t2);\n\t\t}\n \t\tc[4*i+j] = s1;\n\t }\n\t}\n\t\n }\n}\n\n\n\t \n">>] Still alive3 Created program from source Still alive2.5 Port: ecl_port Code: 44 Args <<112,119,136,1,0,0,0,0,3,0,0,0>> Still alive3 Still alive2.5 Port: ecl_port Code: 51 Args <<112,119,136,1,0,0,0,0,160,255, 113,1,0,0,0,0,2,0,0,0>> Still alive3 Still alive2.5 Port: ecl_port Code: 51 Args <<112,119,136,1,0,0,0,0,16,0,114,1, 0,0,0,0,2,0,0,0>> Still alive3 Logs: Still alive Still alive2 Still alive2.5 Port: ecl_port Code: 42 Args <<112,119,136,1,0,0,0,0,2,0,0,0,0, 0,0,0,160,255,113,1,0,0,0,0,16,0, 114,1,0,0,0,0>> Segmentation fault From anthony.shipman@REDACTED Fri Dec 3 03:45:41 2010 From: anthony.shipman@REDACTED (anthony.shipman@REDACTED) Date: Fri, 3 Dec 2010 13:45:41 +1100 Subject: fix of hipe crashes in gc Message-ID: <201012031345.41607.anthony.shipman@symstream.com> I see that the following bug fix is in R14B. I need to stay with a R12B system. Would it be OK to apply the same patch to a R12B system (ie copy the change as in R14B)? Are there any related bug fixes for running native code? I have already seen >fix native code crash when calling unloaded module with on_l >Posted: Wed Jun 30, 2010 12:32 pm -------------------------------------------- Posted: Sat Jul 17, 2010 1:08 pm Hello, I have been experiencing crashes in the garbage collector when running erlang with natively compiled modules, and especially with OTP configured with --enable-native-libs. This has been discussed before, including by others: http://www.erlang.org/cgi-bin/ezmlm-cgi/4/50033 http://www.erlang.org/cgi-bin/ezmlm-cgi/4/39462 http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1583 I finally got a reproduceable case and nailed the bug down. The bug was introduced in R12B-0, when the function erts_gc_after_bif_call was updated to take 4 parameters but the assembly glue code was not updated to pass proper values for the third and fourth parameters. A fix is available here: git fetch git://github.com/pguyot/otp.git pg/fix-hipe-crash-in-gc_after_bif http://github.com/pguyot/otp/commit/c42ba9962d7e83accec797c56e5480a2d0b6281a Please note that I only tested it on x86 and amd64 platforms. Regards, Paul -- Anthony Shipman | Programming is like sex: One mistake and Anthony.Shipman@REDACTED | you're providing support for a lifetime. From kostis@REDACTED Fri Dec 3 08:20:45 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 03 Dec 2010 09:20:45 +0200 Subject: [erlang-bugs] Re: fix of hipe crashes in gc In-Reply-To: <201012031345.41607.anthony.shipman@symstream.com> References: <201012031345.41607.anthony.shipman@symstream.com> Message-ID: <4CF89A4D.7080307@cs.ntua.gr> anthony.shipman@REDACTED wrote: > I see that the following bug fix is in R14B. I need to stay with a R12B > system. Would it be OK to apply the same patch to a R12B system (ie copy the > change as in R14B)? Most probably yes. > Are there any related bug fixes for running native code? I have already seen > >> fix native code crash when calling unloaded module with on_l >> Posted: Wed Jun 30, 2010 12:32 pm I am pretty sure you do not need the above fix as "on_load" was introduced after R12B. But you may want to also apply the fix at: https://github.com/pguyot/otp/commit/e56566abf406cc21a70bc3064408166974c48636 Kostis From ulf.norell@REDACTED Mon Dec 6 09:54:56 2010 From: ulf.norell@REDACTED (Ulf Norell) Date: Mon, 6 Dec 2010 09:54:56 +0100 Subject: Negative indices in array:to_orddict/1 Message-ID: I was playing around with some simple QuickCheck properties for the array library when I ran into the following weird behaviour: 1> A = array:set(10, b, array:relax(array:resize(0, array:set(10, a, array:new())))). ... 2> io:format("~w~n", [array:to_orddict(A)]). [{-90,undefined},{-89,undefined},{-88,undefined},{-87,undefined},{-86,undefined},{-85,undefined},{-84,undefined},{-83,undefined},{-82,undefined},{-81,undefined},{-80,a},{-79,undefined},{-78,undefined},{-77,undefined},{-76,undefined},{-75,undefined},{-74,undefined},{-73,undefined},{-72,undefined},{-71,undefined},{-70,undefined},{-69,undefined},{-68,undefined},{-67,undefined},{-66,undefined},{-65,undefined},{-64,undefined},{-63,undefined},{-62,undefined},{-61,undefined},{-60,undefined},{-59,undefined},{-58,undefined},{-57,undefined},{-56,undefined},{-55,undefined},{-54,undefined},{-53,undefined},{-52,undefined},{-51,undefined},{-50,undefined},{-49,undefined},{-48,undefined},{-47,undefined},{-46,undefined},{-45,undefined},{-44,undefined},{-43,undefined},{-42,undefined},{-41,undefined},{-40,undefined},{-39,undefined},{-38,undefined},{-37,undefined},{-36,undefined},{-35,undefined},{-34,undefined},{-33,undefined},{-32,undefined},{-31,undefined},{-30,undefined},{-29,undefined},{-28,undefined},{-27,undefined},{-26,undefined},{-25,undefined},{-24,undefined},{-23,undefined},{-22,undefined},{-21,undefined},{-20,undefined},{-19,undefined},{-18,undefined},{-17,undefined},{-16,undefined},{-15,undefined},{-14,undefined},{-13,undefined},{-12,undefined},{-11,undefined},{-10,undefined},{-9,undefined},{-8,undefined},{-7,undefined},{-6,undefined},{-5,undefined},{-4,undefined},{-3,undefined},{-2,undefined},{-1,undefined},{0,undefined},{1,undefined},{2,undefined},{3,undefined},{4,undefined},{5,undefined},{6,undefined},{7,undefined},{8,undefined},{9,undefined},{10,b}] Using a number smaller than 10 gives the expected result (indices 0 to N). Numbers bigger than 10 results in the same weird behaviour as 10. / Ulf From eriksoe@REDACTED Tue Dec 7 01:34:11 2010 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 07 Dec 2010 01:34:11 +0100 Subject: Erlang segfaults in erts_remove_monitor Message-ID: <4CFD8103.7040309@gmail.com> Hi there - while working on the distribution subsystem of Erjang, I ran into this: beam core dumping, reproducibly. Setup: (1) An Erjang node[1] is started as j@REDACTED; an Erlang node (R14B) is started as c@REDACTED (2) (c@REDACTED)1> net_adm:ping(j@REDACTED). (3) (j@REDACTED)1> global:register_name(foo, self()), throw(x). Result: Output from c@ : Segmentation fault Output from j@ (mostly distribution-related debugging messages): sending msg {global_name_server,c@REDACTED} ! {'$gen_call',{<1.0.52>,{#Ref,c@REDACTED}},{set_lock,{global,<1.0.52>}}} sending msg {global_name_server,c@REDACTED} ! {'$gen_call',{<1.0.52>,{#Ref,c@REDACTED}},{register,foo,<1.0.518>,#Fun}} sending msg {global_name_server,c@REDACTED} ! {'$gen_call',{<1.0.52>,{#Ref,c@REDACTED}},{del_lock,{global,<1.0.52>}}} ** exception throw: x in function apply/3 [snip stack trace] Reproducing the problem with GDB attached reveals this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6413b70 (LWP 4282)] erts_remove_monitor (root=0x94495b0, ref=587) at beam/erl_monitors.c:615 615 } else if ((c = CMP_MON_REF(ref,(*this)->ref)) < 0) { with the stack trace #0 erts_remove_monitor (root=0x94495b0, ref=587) at beam/erl_monitors.c:615 #1 0x081021d1 in erts_net_message (prt=0xb75adb60, dep=0x9449530, hbuf=0x0, hlen=0, buf=0x946aabc "\203D", len=57) at beam/dist.c:1274 #2 0x080d0b6e in driver_output2 (ix=609, hbuf=0x946aabc "\203D", hlen=57, buf=0x0, len=0) at beam/io.c:3277 #3 0x081adede in inet_port_data (desc=0x94a9388, len=61) at drivers/common/inet_drv.c:1889 #4 tcp_reply_data (desc=0x94a9388, len=61) at drivers/common/inet_drv.c:3174 #5 tcp_deliver (desc=0x94a9388, len=61) at drivers/common/inet_drv.c:7916 [snip] I don't know what to look for here, but...: (gdb) print this $1 = (ErtsMonitor **) 0x94495b0 (gdb) print *this $2 = (ErtsMonitor *) 0xb761f77c (gdb) print (*this)->ref $3 = 3076650902 (gdb) print c $4 = (gdb) print ref $5 = 587 As far as I can tell, ref is the odd value here (should be pointer-like, right?). Hoping this will make sense to someone, Erik S?e S?rensen [1] Erjang version in question is this one: https://github.com/eriksoe/erjang/commit/637f9d9fca97901b941a7ef6b1bbba95ddc98094 From tuncer.ayaz@REDACTED Wed Dec 8 22:57:50 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 8 Dec 2010 22:57:50 +0100 Subject: filename.erl native compile hang Message-ID: When building a --enable-native-libs configured otp.git dev tree it takes an indefinite amount of time to compile filename.erl natively. Without --enable-native-libs it works. A quick bisect revealed: 4cf08709189ea8b7e2ae20f85c390abd04ae48ae is the first bad commit commit 4cf08709189ea8b7e2ae20f85c390abd04ae48ae Author: Patrik Nyblom Date: Wed Oct 13 17:08:32 2010 +0200 Teach filename to accept raw data and add filename enc option to emu :040000 040000 d28390c9db2b82038400e18214cb662adcba9e73 f0e669ceebd50ec1c93747b5ef088f9624ae8e5f M erts :040000 040000 049cf26200961246118308baa458aff5336d914b b5dfd3c945c33ee820013759cf1c36f2dfaa9243 M lib From spawn.think@REDACTED Fri Dec 10 14:00:32 2010 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 10 Dec 2010 14:00:32 +0100 Subject: race condition in the concurrency profiler (percept)? Message-ID: In percept_db, the function start/1 if it find an instance running , it will send a message to stop the running db and spawn a process to start a new one, which leads to a race condition. It can be reproduced with enough stress testing. But one way to easily reproduce it, you can call percept:analyze/2 two subsequent times. 63> percept:analyze("test.dat"). Parsing: "test.dat" =ERROR REPORT==== 10-Dec-2010::13:52:46 === Error in process <0.252.0> with exit value: {badarg,[{ets,new,[pdb_info,[named_table,private,{keypos,2},set]]},{percept_db,init_percept_db,0}]} =ERROR REPORT==== 10-Dec-2010::13:52:46 === Error in process <0.253.0> with exit value: {badarg,[{percept_db,insert,1},{percept,trace_parser,2},{dbg,tc_loop,3}]} {error,{badarg,[{percept_db,insert,1}, {percept,trace_parser,2}, {dbg,tc_loop,3}]}} -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think From spawn.think@REDACTED Fri Dec 10 14:27:24 2010 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 10 Dec 2010 14:27:24 +0100 Subject: race condition in the concurrency profiler (percept)? In-Reply-To: References: Message-ID: if you confirm it's a bug i can submit a patch supported with a test case On Fri, Dec 10, 2010 at 2:00 PM, Ahmed Omar wrote: > In percept_db, the function start/1 if it find an instance running , it > will send a message to stop the running db and spawn a process to start a > new one, which leads to a race condition. > > It can be reproduced with enough stress testing. But one way to easily > reproduce it, you can call percept:analyze/2 two subsequent times. > > 63> percept:analyze("test.dat"). > Parsing: "test.dat" > > =ERROR REPORT==== 10-Dec-2010::13:52:46 === > Error in process <0.252.0> with exit value: > {badarg,[{ets,new,[pdb_info,[named_table,private,{keypos,2},set]]},{percept_db,init_percept_db,0}]} > > > =ERROR REPORT==== 10-Dec-2010::13:52:46 === > Error in process <0.253.0> with exit value: > {badarg,[{percept_db,insert,1},{percept,trace_parser,2},{dbg,tc_loop,3}]} > > {error,{badarg,[{percept_db,insert,1}, > {percept,trace_parser,2}, > {dbg,tc_loop,3}]}} > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think From ulf.wiger@REDACTED Sat Dec 11 12:46:45 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 11 Dec 2010 12:46:45 +0100 Subject: mnesia dumps core when merging schema mods Message-ID: - start mnesia on N1 with a disk schema - create a table, t, with {disc_copies, [N1]} - start N2 with {extra_db_nodes,[N1]} - run mnesia:change_table_copy_type(schema,N2,disc_copies) - on N2, mnesia:add_table_copy(t, N2, disc_copies) - start N3 the same way - kill N1 - change N3's schema to disc_copies - on N3, mnesia:add_table_copy(t, N3, ram_copies). - restart N1, start mnesia on N1 (it now knows of N3's ram_copy of t) - kill N1 again - on N3, mnesia:change_table_copy_type(t, N3, disc_copies). - restart N1 Mnesia now dumps core on N1, since it finds both a ram_copy and a disc_copy entry of table t for N3. This was from the start a completely made up example, so I don't know of any crisis involving any live system due to this. Still, mnesia should handle the situation better. BR, Ulf Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From ulf.wiger@REDACTED Mon Dec 13 07:29:51 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 13 Dec 2010 07:29:51 +0100 Subject: mnesia:lock(Item, sticky_write) bad return value Message-ID: <7AB428DF-392D-4F9A-BE64-9222676DF34C@erlang-solutions.com> Eshell V5.8.1 (abort with ^G) 1> mnesia:create_schema([node()]). ok 2> mnesia:start(). ok 3> mnesia:create_table(t,[{ram_copies,[node()]}]). {atomic,ok} 4> mnesia:transaction(fun() -> mnesia:lock({table,t},sticky_write) end). {atomic,[nonode@REDACTED]} 5> mnesia:transaction(fun() -> mnesia:lock({table,t},sticky_write) end). {atomic,granted} According to the manual, mnesia:lock/2 returns Nodes | ok | transaction abort When using the lock type sticky_write, you get the correct return value the first time, but not for subsequent calls. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From kostis@REDACTED Mon Dec 13 16:01:19 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 13 Dec 2010 17:01:19 +0200 Subject: [erlang-bugs] filename.erl native compile hang In-Reply-To: References: Message-ID: <4D06353F.3030603@cs.ntua.gr> Tuncer Ayaz wrote: > When building a --enable-native-libs configured otp.git dev tree it > takes an indefinite amount of time to compile filename.erl natively. > Without --enable-native-libs it works. > > A quick bisect revealed: > 4cf08709189ea8b7e2ae20f85c390abd04ae48ae is the first bad commit > commit 4cf08709189ea8b7e2ae20f85c390abd04ae48ae > Author: Patrik Nyblom > Date: Wed Oct 13 17:08:32 2010 +0200 > > Teach filename to accept raw data and add filename enc option to emu > > :040000 040000 d28390c9db2b82038400e18214cb662adcba9e73 > f0e669ceebd50ec1c93747b5ef088f9624ae8e5f M erts > :040000 040000 049cf26200961246118308baa458aff5336d914b > b5dfd3c945c33ee820013759cf1c36f2dfaa9243 M lib This problem (and some other ones related to the introduction of unicode binaries as filenames) has been fixed: git fetch git://github.com/kostis/otp.git r14b01-patch Kostis From spawn.think@REDACTED Mon Dec 13 18:05:26 2010 From: spawn.think@REDACTED (Ahmed Omar) Date: Mon, 13 Dec 2010 18:05:26 +0100 Subject: race condition in the concurrency profiler (percept)? In-Reply-To: References: Message-ID: Any feedback? On Fri, Dec 10, 2010 at 2:27 PM, Ahmed Omar wrote: > if you confirm it's a bug i can submit a patch supported with a test case > > > On Fri, Dec 10, 2010 at 2:00 PM, Ahmed Omar wrote: > >> In percept_db, the function start/1 if it find an instance running , it >> will send a message to stop the running db and spawn a process to start a >> new one, which leads to a race condition. >> >> It can be reproduced with enough stress testing. But one way to easily >> reproduce it, you can call percept:analyze/2 two subsequent times. >> >> 63> percept:analyze("test.dat"). >> Parsing: "test.dat" >> >> =ERROR REPORT==== 10-Dec-2010::13:52:46 === >> Error in process <0.252.0> with exit value: >> {badarg,[{ets,new,[pdb_info,[named_table,private,{keypos,2},set]]},{percept_db,init_percept_db,0}]} >> >> >> =ERROR REPORT==== 10-Dec-2010::13:52:46 === >> Error in process <0.253.0> with exit value: >> {badarg,[{percept_db,insert,1},{percept,trace_parser,2},{dbg,tc_loop,3}]} >> >> {error,{badarg,[{percept_db,insert,1}, >> {percept,trace_parser,2}, >> {dbg,tc_loop,3}]}} >> >> >> -- >> Best Regards, >> - Ahmed Omar >> http://nl.linkedin.com/in/adiaa >> Follow me on twitter >> @spawn_think >> >> > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think From tuncer.ayaz@REDACTED Mon Dec 13 20:34:13 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 13 Dec 2010 20:34:13 +0100 Subject: [erlang-bugs] filename.erl native compile hang In-Reply-To: <4D06353F.3030603@cs.ntua.gr> References: <4D06353F.3030603@cs.ntua.gr> Message-ID: On Mon, Dec 13, 2010 at 4:01 PM, Kostis Sagonas wrote: > Tuncer Ayaz wrote: >> >> When building a --enable-native-libs configured otp.git dev tree it >> takes an indefinite amount of time to compile filename.erl natively. >> Without --enable-native-libs it works. >> >> A quick bisect revealed: >> 4cf08709189ea8b7e2ae20f85c390abd04ae48ae is the first bad commit >> commit 4cf08709189ea8b7e2ae20f85c390abd04ae48ae >> Author: Patrik Nyblom >> Date: Wed Oct 13 17:08:32 2010 +0200 >> >> Teach filename to accept raw data and add filename enc option to emu >> >> :040000 040000 d28390c9db2b82038400e18214cb662adcba9e73 >> f0e669ceebd50ec1c93747b5ef088f9624ae8e5f M erts >> :040000 040000 049cf26200961246118308baa458aff5336d914b >> b5dfd3c945c33ee820013759cf1c36f2dfaa9243 M lib > > This problem (and some other ones related to the introduction of unicode > binaries as filenames) has been fixed: > > git fetch git://github.com/kostis/otp.git r14b01-patch Confirmed. Thanks! From terryzsmith@REDACTED Mon Dec 13 23:59:49 2010 From: terryzsmith@REDACTED (Terry Smith) Date: Mon, 13 Dec 2010 17:59:49 -0500 Subject: erlsrv.exe terminates unexpectedly running a CouchDB unit test on Windows Server 2008 In-Reply-To: References: Message-ID: I originally posted this in the CouchDB bug database as https://issues.apache.org/jira/browse/COUCHDB-963. Here's a copy of the report: *Environment: * This Windows box is a virtual machine Windows Server 2008 Standard without Hyper-V Service Pack 2 64-bit 2 GB RAM 2 Core Intel Xeon CPU @ 2.53GHz each *Description:* Install 1.0.1 CouchDB as a service using the Windows Binary Installer ( http://people.apache.org/~mhammond/dist/1.0.1/). I did not select to "Start service after installation". Edit the local.ini to set the logging level to "debug". Go to the service control panel and start the Apache CouchDB service. Go to Test Suite in Futon (use Firefox and goto http://localhost:5984/_utils/couch_tests.html?script/couch_tests.js) and run the "delayed_commits" test. After about 15 - 20 seconds go to the service control panel and refresh to see that the service is no longer running. ProcessExplorer verifies the erlsrv.exe and erl.exe processes are not running. The last message in the the couch log is a _restart command. When I run CouchDB using C:\Program Files\Apache Software Foundation\CouchDB\bin\CouchDB.bat. The test completes without crashing. I've tested on another Windows Server 2008 VM and the test runs successfully after starting up CouchDB, however, the test fails with the crash when running it a second time. When I set the DebugType in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Ericsson\Erlang\ErlSrv\1.1\Apache CouchDB to 1 (DEBUG_TYPE_NEW) to get a erlsrv.exe log, the test completes without crashing. I built a version of erlsrv.exe to always output the existing debug messages and the message: *"Erlang machine volountarily stopped. The service is not restarted as OnFail is set to ignore."* is output. When console output is directed to a file or to a console the crash does not happen. *Attachments:* erl_crash.dump is in erl_crash.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: erl_crash.zip Type: application/zip Size: 55738 bytes Desc: not available URL: From kruber@REDACTED Tue Dec 14 11:57:24 2010 From: kruber@REDACTED (Nico Kruber) Date: Tue, 14 Dec 2010 11:57:24 +0100 Subject: R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) Message-ID: <201012141157.28759.kruber@zib.de> Most distributions nowadays adds the -D_FORTIFY_SOURCE=2 flag during package compilation. I tried updating my erlang package (openSUSE 11.3, x86_64) from R14B to R14B01 and received the following error (also see the attached build.log.fortsource2 - compressed due to its file size): *** buffer overflow detected ***: /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x2b64930b0067] /lib64/libc.so.6(+0xe4e10)[0x2b64930ade10] /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x584047] /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(erts_write_to_port+0x97f)[0x4946ef] /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x50fcb9] /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(process_main+0x2eba)[0x53b36a] /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x4a1772] /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x5aee94] /lib64/libpthread.so.0(+0x6a4f)[0x2b6492ba8a4f] /lib64/libc.so.6(clone+0x6d)[0x2b649309982d] Setting -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer overflow is probably still there and dangerous... R14B did not show this behaviour. Additionally, could you correct the dependencies in the makefiles in order to allow make -j2 and higher? Regards Nico Kruber -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log.fortsource2.gz Type: application/x-gzip Size: 19577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From fauli@REDACTED Tue Dec 14 13:17:43 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Tue, 14 Dec 2010 13:17:43 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <201012141157.28759.kruber@zib.de> References: <201012141157.28759.kruber@zib.de> Message-ID: <20101214131743.27b587dc@gentoo.org> Hi, Nico Kruber : > Setting -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer > overflow is probably still there and dangerous... R14B did not show > this behaviour. Maybe this hides a security problems? > Additionally, could you correct the dependencies in the makefiles in > order to allow make -j2 and higher? Is this safe now? Gentoo builds with -j1 for ages because of problems reported with Erlang 11. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kruber@REDACTED Tue Dec 14 13:52:41 2010 From: kruber@REDACTED (Nico Kruber) Date: Tue, 14 Dec 2010 13:52:41 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <20101214131743.27b587dc@gentoo.org> References: <201012141157.28759.kruber@zib.de> <20101214131743.27b587dc@gentoo.org> Message-ID: <201012141352.47691.kruber@zib.de> On Tuesday 14 December 2010 13:17:43 Christian Faulhammer wrote: > Hi, > > Nico Kruber : > > Setting -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer > > overflow is probably still there and dangerous... R14B did not show > > this behaviour. > > Maybe this hides a security problems? that's what I suspected, too (it merely hides the error) > > Additionally, could you correct the dependencies in the makefiles in > > order to allow make -j2 and higher? > > Is this safe now? Gentoo builds with -j1 for ages because of problems > reported with Erlang 11. no - I tried with -j2 and it does not work yet :( -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From burbas@REDACTED Tue Dec 14 14:01:04 2010 From: burbas@REDACTED (Niclas Axelsson) Date: Tue, 14 Dec 2010 14:01:04 +0100 Subject: [erlang-bugs] Re: fix of hipe crashes in gc In-Reply-To: <4CF89A4D.7080307@cs.ntua.gr> References: <201012031345.41607.anthony.shipman@symstream.com> <4CF89A4D.7080307@cs.ntua.gr> Message-ID: <4D076A90.1010903@erlang.org> On 12/03/2010 08:20 AM, Kostis Sagonas wrote: > anthony.shipman@REDACTED wrote: >> I see that the following bug fix is in R14B. I need to stay with a >> R12B system. Would it be OK to apply the same patch to a R12B system >> (ie copy the change as in R14B)? > > Most probably yes. > >> Are there any related bug fixes for running native code? I have >> already seen >> >>> fix native code crash when calling unloaded module with on_l >>> Posted: Wed Jun 30, 2010 12:32 pm > > I am pretty sure you do not need the above fix as "on_load" was > introduced after R12B. But you may want to also apply the fix at: > > https://github.com/pguyot/otp/commit/e56566abf406cc21a70bc3064408166974c48636 > > > Kostis > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED Thanks for the patch. Will include it into 'pu'. I'm sorry for the late response, but patches like this should be posted on the erlang-patches, and not here. So in the future, please use the erlang-patches for posting patches. Regards, Niclas Axelsson, Erlang/OTP From burbas@REDACTED Tue Dec 14 14:04:20 2010 From: burbas@REDACTED (Niclas Axelsson) Date: Tue, 14 Dec 2010 14:04:20 +0100 Subject: [erlang-bugs] filename.erl native compile hang In-Reply-To: <4D06353F.3030603@cs.ntua.gr> References: <4D06353F.3030603@cs.ntua.gr> Message-ID: <4D076B54.8000306@erlang.org> On 12/13/2010 04:01 PM, Kostis Sagonas wrote: > Tuncer Ayaz wrote: >> When building a --enable-native-libs configured otp.git dev tree it >> takes an indefinite amount of time to compile filename.erl natively. >> Without --enable-native-libs it works. >> >> A quick bisect revealed: >> 4cf08709189ea8b7e2ae20f85c390abd04ae48ae is the first bad commit >> commit 4cf08709189ea8b7e2ae20f85c390abd04ae48ae >> Author: Patrik Nyblom >> Date: Wed Oct 13 17:08:32 2010 +0200 >> >> Teach filename to accept raw data and add filename enc option to emu >> >> :040000 040000 d28390c9db2b82038400e18214cb662adcba9e73 >> f0e669ceebd50ec1c93747b5ef088f9624ae8e5f M erts >> :040000 040000 049cf26200961246118308baa458aff5336d914b >> b5dfd3c945c33ee820013759cf1c36f2dfaa9243 M lib > > This problem (and some other ones related to the introduction of > unicode binaries as filenames) has been fixed: > > git fetch git://github.com/kostis/otp.git r14b01-patch > > > Kostis > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED Hi Kostis, thanks for the patch, will include it in 'pu'. Regards, Niclas Axelsson, Erlang/OTP From kostis@REDACTED Tue Dec 14 14:08:17 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 14 Dec 2010 15:08:17 +0200 Subject: [erlang-bugs] filename.erl native compile hang In-Reply-To: <4D076B54.8000306@erlang.org> References: <4D06353F.3030603@cs.ntua.gr> <4D076B54.8000306@erlang.org> Message-ID: <4D076C41.7070202@cs.ntua.gr> Niclas Axelsson wrote: > On 12/13/2010 04:01 PM, Kostis Sagonas wrote: >> Tuncer Ayaz wrote: >>> When building a --enable-native-libs configured otp.git dev tree it >>> takes an indefinite amount of time to compile filename.erl natively. >>> Without --enable-native-libs it works. >>> >>> ... >> >> This problem (and some other ones related to the introduction of >> unicode binaries as filenames) has been fixed: >> >> git fetch git://github.com/kostis/otp.git r14b01-patch >> > > Hi Kostis, > thanks for the patch, will include it in 'pu'. Actually, this patch should probably be included directly (or at least as soon as possible) into 'dev'. Kostis From burbas@REDACTED Tue Dec 14 17:28:04 2010 From: burbas@REDACTED (Niclas Axelsson) Date: Tue, 14 Dec 2010 17:28:04 +0100 Subject: [erlang-bugs] Re: fix of hipe crashes in gc In-Reply-To: <4D076A90.1010903@erlang.org> References: <201012031345.41607.anthony.shipman@symstream.com> <4CF89A4D.7080307@cs.ntua.gr> <4D076A90.1010903@erlang.org> Message-ID: <4D079B14.7060104@erlang.org> On 12/14/2010 02:01 PM, Niclas Axelsson wrote: > On 12/03/2010 08:20 AM, Kostis Sagonas wrote: >> anthony.shipman@REDACTED wrote: >>> I see that the following bug fix is in R14B. I need to stay with a >>> R12B system. Would it be OK to apply the same patch to a R12B system >>> (ie copy the change as in R14B)? >> >> Most probably yes. >> >>> Are there any related bug fixes for running native code? I have >>> already seen >>> >>>> fix native code crash when calling unloaded module with on_l >>>> Posted: Wed Jun 30, 2010 12:32 pm >> >> I am pretty sure you do not need the above fix as "on_load" was >> introduced after R12B. But you may want to also apply the fix at: >> >> https://github.com/pguyot/otp/commit/e56566abf406cc21a70bc3064408166974c48636 >> >> >> Kostis >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > Thanks for the patch. Will include it into 'pu'. I'm sorry for the > late response, but patches > like this should be posted on the erlang-patches, and not here. So in > the future, please > use the erlang-patches for posting patches. > > Regards, > Niclas Axelsson, Erlang/OTP > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED Sorry about the confusion. Did not read the thread as careful as I should have. But as Kostis said, you might want to apply the fix he posted. Regards, Niclas Axelsson, Erlang/OTP From steven.charles.davis@REDACTED Wed Dec 15 10:54:29 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Wed, 15 Dec 2010 03:54:29 -0600 Subject: Slow make, failing function_exported, Windows only? Message-ID: <4D089055.8050704@gmail.com> Hi, Since 14B01, make:all() is suddenly awfully slow for me. I've also had problems with erlang:function_exported. Where module_info shows that the particular function is exported, erlang:function_exported/2 is returning false. Are these two symptoms perhaps connected? The system is Windows XP2, using make in werl repl. I did use the uninstaller for 14B after installing 14B01 (which is normally fine); And so this could feasibly mean that it's just my local setup. I'll investigate further, but I wondered whether anyone else has noticed these issues? Regards, Steve From skunk@REDACTED Wed Dec 15 19:51:34 2010 From: skunk@REDACTED (Daniel Richard G.) Date: Wed, 15 Dec 2010 13:51:34 -0500 Subject: xsltproc error: "Unsupported encoding latin1" Message-ID: <1292439094.28721.1410518831@webmail.messagingengine.com> I encountered this error in attempting to build the R14 Debian source package on Ubuntu Maverick, and likewise when building the man pages from git: -------- hostname:/tmp/erlang-build/lib/dialyzer/doc/src$ make man ERL_TOP=/tmp/erlang-build date=`date +"%B %e %Y"`; \ xsltproc --output "../man3/dialyzer.3" --stringparam company "Ericsson AB" --stringparam docgen "/tmp/erlang-build/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "dialyzer" --stringparam appver "2.4.0" --xinclude -path /tmp/erlang-build/lib/erl_docgen/priv/docbuilder_dtd -path /tmp/erlang-build/lib/erl_docgen/priv/dtd_man_entities /tmp/erlang-build/lib/erl_docgen/priv/xsl/db_man.xsl dialyzer.xml dialyzer.xml:1: parser error : Unsupported encoding latin1 ^ unable to parse dialyzer.xml make: *** [../man3/dialyzer.3] Error 6 -------- Every single XML file that specifies encoding="latin1" causes xsltproc(1) to choke. If I edit the XML to specify e.g. encoding="iso-8859-1" instead, it works. Given that "latin1" is an alias, and "iso-8859-1" (or a syntactic variant thereof) the canonical form, it may be advisable to have all XML headers in that encoding use the latter. --Daniel -- NAME = Daniel Richard G. _\|/_ Remember, skunks MAIL = skunk@REDACTED (/o|o\) _- don't smell bad--- MAIL+= skunk@REDACTED < (^),> it's the people who WWW = (not there yet!) / \ annoy us that do! From jimenezrick@REDACTED Thu Dec 16 16:49:49 2010 From: jimenezrick@REDACTED (=?UTF-8?Q?Ricardo_Catalinas_Jim=C3=A9nez?=) Date: Thu, 16 Dec 2010 16:49:49 +0100 Subject: Typo in RPC doc Message-ID: Hi, - From the doc of the `rpc' module: pmap({Module, Function}, ExtraArgs, List2) -> List1 "Evaluates apply(Module, Function, [Elem|ExtraArgs]), for every element Elem in List1, in parallel. Returns the list of return values, in the same order as in List1." Should be --> pmap({Module, Function}, ExtraArgs, List1) -> List2 - One last issue, about this message I wrote to `erlang-questions': Using systools:make_script() raises "*WARNING* inets: Source code not found" (http://www.erlang.org/cgi-bin/ezmlm-cgi?4:msp:55070:oplpdhanejbhhhgodckm) Should `systools:make_script()' traverse subdirectories in app/src/? Thanks in advance. -- Ricardo From fauli@REDACTED Fri Dec 17 16:59:38 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Fri, 17 Dec 2010 16:59:38 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <201012141157.28759.kruber@zib.de> References: <201012141157.28759.kruber@zib.de> Message-ID: <20101217165938.68fdaa1f@gentoo.org> Hi, Nico Kruber : > Most distributions nowadays adds the -D_FORTIFY_SOURCE=2 flag during > package compilation. I tried updating my erlang package (openSUSE > 11.3, x86_64) from R14B to R14B01 and received the following error > (also see the attached build.log.fortsource2 - compressed due to its > file size): [...] > Setting -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer > overflow is probably still there and dangerous... R14B did not show > this behaviour. As you can see, a lot of people are hitting this problem on Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=348559 Is there a fix available already somewhere? V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From steven.charles.davis@REDACTED Mon Dec 20 03:04:01 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sun, 19 Dec 2010 20:04:01 -0600 Subject: Slow make, failing function_exported, Windows only? In-Reply-To: <4D089055.8050704@gmail.com> References: <4D089055.8050704@gmail.com> Message-ID: <4D0EB991.3010707@gmail.com> Upon investigation, and a reinstall, it seems this was a local issue. On 15/12/2010 03:54, Steve Davis wrote: > Hi, > > Since 14B01, make:all() is suddenly awfully slow for me. > > I've also had problems with erlang:function_exported. Where module_info > shows that the particular function is exported, > erlang:function_exported/2 is returning false. > > Are these two symptoms perhaps connected? > > The system is Windows XP2, using make in werl repl. > > I did use the uninstaller for 14B after installing 14B01 (which is > normally fine); And so this could feasibly mean that it's just my local > setup. > > I'll investigate further, but I wondered whether anyone else has noticed > these issues? > > Regards, > Steve From kenneth.lundin@REDACTED Tue Dec 21 10:06:13 2010 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 21 Dec 2010 10:06:13 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <201012141157.28759.kruber@zib.de> References: <201012141157.28759.kruber@zib.de> Message-ID: Hi, Some questions Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any buffer overflow? I am asking because we are running Valgrind extensively before every release and shouldn't buffer overflows be detected there as well? As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by Redhat and =2 can also report buffer flow for code that is correct. If this buffer overflow indeed is a real bug then of course we want to find it and correct it. /Kenneth Erlang/OTP Ericsson On Tue, Dec 14, 2010 at 11:57 AM, Nico Kruber wrote: > Most distributions nowadays adds the -D_FORTIFY_SOURCE=2 flag during package compilation. I tried updating my erlang package (openSUSE 11.3, x86_64) from R14B to R14B01 and received the following error (also see the attached build.log.fortsource2 - compressed due to its file size): > > *** buffer overflow detected ***: /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp terminated > ======= Backtrace: ========= > /lib64/libc.so.6(__fortify_fail+0x37)[0x2b64930b0067] > /lib64/libc.so.6(+0xe4e10)[0x2b64930ade10] > /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x584047] > /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(erts_write_to_port+0x97f)[0x4946ef] > /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x50fcb9] > /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(process_main+0x2eba)[0x53b36a] > /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x4a1772] > /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x5aee94] > /lib64/libpthread.so.0(+0x6a4f)[0x2b6492ba8a4f] > /lib64/libc.so.6(clone+0x6d)[0x2b649309982d] > > > Setting -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer overflow is probably still there and dangerous... > R14B did not show this behaviour. > > Additionally, could you correct the dependencies in the makefiles in order to allow make -j2 and higher? > > > Regards > Nico Kruber > From fauli@REDACTED Tue Dec 21 11:56:31 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Tue, 21 Dec 2010 11:56:31 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: References: <201012141157.28759.kruber@zib.de> Message-ID: <20101221115631.13a01a80@gentoo.org> Hi, Kenneth Lundin : > Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any > buffer overflow? There would have been reports (I maintain the package for Gentoo, where users build the package on their system)...and there were none. We use FORTIFY_SOURCE for some time now. > As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by > Redhat and =2 can also report buffer flow for code that is correct. It is included in the trunk version and used by many distributions nowadays, especially for the server/hardened systems. > If this buffer overflow indeed is a real bug then of course we want to > find it and correct it. Would be nice. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kruber@REDACTED Tue Dec 21 12:10:42 2010 From: kruber@REDACTED (Nico Kruber) Date: Tue, 21 Dec 2010 12:10:42 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <20101221115631.13a01a80@gentoo.org> References: <201012141157.28759.kruber@zib.de> <20101221115631.13a01a80@gentoo.org> Message-ID: <201012211210.47937.kruber@zib.de> On Tuesday 21 December 2010 11:56:31 Christian Faulhammer wrote: > Kenneth Lundin : > > Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any > > buffer overflow? > > There would have been reports (I maintain the package for Gentoo, > where users build the package on their system)...and there were none. > We use FORTIFY_SOURCE for some time now. I can second this for openSUSE 11.3 - FORTIFY_SOURCE has been used before and R14B did not show this overflow (as mentioned in my first email) > > As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by > > Redhat and =2 can also report buffer flow for code that is correct. > > It is included in the trunk version and used by many distributions > nowadays, especially for the server/hardened systems. > > > If this buffer overflow indeed is a real bug then of course we want to > > find it and correct it. > > Would be nice. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From spawn.think@REDACTED Wed Dec 22 13:12:21 2010 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 22 Dec 2010 13:12:21 +0100 Subject: Typos in User guide? Message-ID: Hi there, I was wondering if the user guide and efficiency guide were somehow under git repo? The reason is, they contain few typos needed to be fixed 1) In installation guide : http://www.erlang.org/doc/installation_guide/INSTALL.html#id57755 mensioned -> mentioned 2) In efficiency guide : http://www.erlang.org/doc/efficiency_guide/processes.html it will *it* grow it -> it will grow it -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think From egil@REDACTED Wed Dec 22 14:37:38 2010 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 22 Dec 2010 14:37:38 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <20101221115631.13a01a80@gentoo.org> References: <201012141157.28759.kruber@zib.de> <20101221115631.13a01a80@gentoo.org> Message-ID: <4D11FF22.6050706@erix.ericsson.se> Hi, I am trying to reproduce this error, but I am sad to say that I seem to be missing something. Now, I am not a build environment expert but this should be straight forward right? First off, this is otp_src_R14B01 with no distribution specific patches applied? Seems unlikely, since both Gentoo and openSUSE hits this error. Now, I don't have any gentoo or opensuse x86_64 available, I have a 32-bit gentoo which doesn't seem to produce this error (i didn't expect it to), and plenty of SuSE sled/sles 10.1 - 2 x86_64, which doesn't have the compiler. I do have some newer x86_64 Ubuntu's so I tried with gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3. This compiler should have the fortify sources patch (default since 9.10). -D_FORTIFY_SOURCE=2 shouldn't be needed since -02 and higher implies this option. A small testprogram confirms that -02 and memcpy check works anyways. But, No luck. I tried emulating what Nico did in his build script, like this, > tar -zxvf otp_src_R14B01.tar.gz > cd otp_src_R14B01 > export ERL_TOP=`pwd` > export 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fno-strict-aliasing' > export 'CXXFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fno-strict-aliasing' > export FFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables' > ./configure --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --with-ssl=/usr --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe --enable-shared-zlib > ulimit -c unlimited > make No errors, all is great. So something is wrong. Either in the assumptions or the setup. Everything from stack-protectors, valgrind and other fortifications says everything is fine. Is the error consistent? Does it appear everytime and on the same file? hipe_rtl.erl? It should anyways. Could someone please give me some pointers on how to reproduce this? // Bj?rn-Egil Erlang/OTP On 2010-12-21 11:56, Christian Faulhammer wrote: > Hi, > > Kenneth Lundin: >> Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any >> buffer overflow? > > There would have been reports (I maintain the package for Gentoo, > where users build the package on their system)...and there were none. > We use FORTIFY_SOURCE for some time now. > >> As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by >> Redhat and =2 can also report buffer flow for code that is correct. > > It is included in the trunk version and used by many distributions > nowadays, especially for the server/hardened systems. > >> If this buffer overflow indeed is a real bug then of course we want to >> find it and correct it. > > Would be nice. > > V-Li > From kruber@REDACTED Wed Dec 22 15:27:30 2010 From: kruber@REDACTED (Nico Kruber) Date: Wed, 22 Dec 2010 15:27:30 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <4D11FF22.6050706@erix.ericsson.se> References: <201012141157.28759.kruber@zib.de> <20101221115631.13a01a80@gentoo.org> <4D11FF22.6050706@erix.ericsson.se> Message-ID: <201012221527.36094.kruber@zib.de> I also tried with a clean R14B01 (without distro-patches and without all the build service "overhead" from the log I provided, e.g. environment variables) - same result. so I just used this (openSUSE 11.3, x86_64, dual-core CPU, GCC is 4.5.0_20100604-1.12): ./configure --with-ssl=/usr --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe --enable-shared-zlib make If you can access the openSUSE BuildService, you can exactly reproduce the environment I (normally) built my packages on: (you can install the osc command line client from a repository in http://software.opensuse.org/download/openSUSE:/Tools/ available for a lot of distributions) osc checkout home:tschuett erlang cd home\:tschuett/erlang osc build --ccache openSUSE_11.3 erlang.spec (--ccache is just for performance in case of re-compilation) It will download all rpms required to build the package and set up a chroot environment for it. You can remove the distribution specific patches as well as my workaround setting D_FORTIFY_SOURCE=1 in the .spec file. The error message is _always_ there and always in the same file. Nico On Wednesday 22 December 2010 14:37:38 Bj?rn-Egil Dahlberg wrote: > Hi, > > I am trying to reproduce this error, but I am sad to say that I seem to > be missing something. Now, I am not a build environment expert but this > should be straight forward right? > > First off, this is otp_src_R14B01 with no distribution specific patches > applied? Seems unlikely, since both Gentoo and openSUSE hits this error. > > Now, I don't have any gentoo or opensuse x86_64 available, I have a > 32-bit gentoo which doesn't seem to produce this error (i didn't expect > it to), and plenty of SuSE sled/sles 10.1 - 2 x86_64, which doesn't have > the compiler. > > I do have some newer x86_64 Ubuntu's so I tried with gcc (Ubuntu > 4.4.3-4ubuntu5) 4.4.3. This compiler should have the fortify sources > patch (default since 9.10). -D_FORTIFY_SOURCE=2 shouldn't be needed > since -02 and higher implies this option. A small testprogram confirms > that -02 and memcpy check works anyways. > > But, No luck. > > I tried emulating what Nico did in his build script, like this, > > tar -zxvf otp_src_R14B01.tar.gz > > cd otp_src_R14B01 > > export ERL_TOP=`pwd` > > export 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector -funwind-tables -fasynchronous-unwind-tables > -fno-strict-aliasing' > > export 'CXXFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector -funwind-tables -fasynchronous-unwind-tables > -fno-strict-aliasing' > > export FFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector -funwind-tables -fasynchronous-unwind-tables' > > ./configure --host=x86_64-unknown-linux-gnu > --build=x86_64-unknown-linux-gnu --with-ssl=/usr --enable-threads > --enable-smp-support --enable-kernel-poll --enable-hipe --enable-shared-zlib > > ulimit -c unlimited > > make > > No errors, all is great. > > > So something is wrong. Either in the assumptions or the setup. > Everything from stack-protectors, valgrind and other fortifications says > everything is fine. > > Is the error consistent? Does it appear everytime and on the same file? > hipe_rtl.erl? It should anyways. > > Could someone please give me some pointers on how to reproduce this? > > // Bj?rn-Egil > Erlang/OTP > > > > On 2010-12-21 11:56, Christian Faulhammer wrote: > > Hi, > > > > Kenneth Lundin: > >> Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any > >> buffer overflow? > > > > There would have been reports (I maintain the package for Gentoo, > > where users build the package on their system)...and there were none. > > We use FORTIFY_SOURCE for some time now. > > > >> As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by > >> Redhat and =2 can also report buffer flow for code that is correct. > > > > It is included in the trunk version and used by many distributions > > nowadays, especially for the server/hardened systems. > > > >> If this buffer overflow indeed is a real bug then of course we want to > >> find it and correct it. > > > > Would be nice. > > > > V-Li -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From fauli@REDACTED Wed Dec 22 17:18:50 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Wed, 22 Dec 2010 17:18:50 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <4D11FF22.6050706@erix.ericsson.se> References: <201012141157.28759.kruber@zib.de> <20101221115631.13a01a80@gentoo.org> <4D11FF22.6050706@erix.ericsson.se> Message-ID: <20101222171850.022f9cf9@gentoo.org> Hi, Bj?rn-Egil Dahlberg : > I am trying to reproduce this error, but I am sad to say that I seem > to be missing something. Now, I am not a build environment expert but > this should be straight forward right? It might be depending on GCC 4.5. 4.4 seems fine. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From wallentin.dahlberg@REDACTED Wed Dec 22 18:21:06 2010 From: wallentin.dahlberg@REDACTED (Wallentin Dahlberg) Date: Wed, 22 Dec 2010 18:21:06 +0100 Subject: [erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64) In-Reply-To: <20101222171850.022f9cf9@gentoo.org> References: <201012141157.28759.kruber@zib.de> <20101221115631.13a01a80@gentoo.org> <4D11FF22.6050706@erix.ericsson.se> <20101222171850.022f9cf9@gentoo.org> Message-ID: <-4005709178650890928@unknownmsgid> My thoughts too. // Bj?rn-Egil Skickat fr?n min iPhone 22 dec 2010 kl. 17:17 skrev Christian Faulhammer : > Hi, > > Bj?rn-Egil Dahlberg : >> I am trying to reproduce this error, but I am sad to say that I seem >> to be missing something. Now, I am not a build environment expert but >> this should be straight forward right? > > It might be depending on GCC 4.5. 4.4 seems fine. > > V-Li > > -- > Christian Faulhammer, Gentoo Lisp project > , #gentoo-lisp on FreeNode > > From jesper.louis.andersen@REDACTED Wed Dec 22 19:08:32 2010 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 22 Dec 2010 19:08:32 +0100 Subject: Parser error regression for ERTS V5.8.3 Message-ID: Consider the following module: == -module(foo). -compile(export_all). -record(foo, { bar }). x() -> [ #foo { bar = 1} #foo { bar = 2} #foo { bar = 3}]. == In ERTS V5.8.3 this is valid (notice the lack of commas at the end of each line). It is also valid in V5.8.1, but it fails on V5.7.4: ./foo.erl:9: syntax error before: '#' ./foo.erl:4: Warning: record foo is unused The result of foo:x(). is: Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> c(foo). {ok,foo} 2> foo:x(). [{foo,3}] 3> which I find highly confusing and wrong. The parse derivation is: expr -> list -> tail -> expr -> record_expr --(by the last clause erl_parse.yrl L351)--> record_expr .... (parse derivation from commit 609e7ade98c) git annotate lib/stdlib/src/erl_parse.yrl points to commit 3829e5fa ..: Support nested record field access without parentheses. ... (omitted rest of the commit) git show 3829e5fa So it has to do with the introduction of nested records without parenthesis. I suggest to revert the patch and add something like the above as a SHOULD_FAIL test case to the parser tests. (We found it on the IRC channel because someone asked why a Nitrogen tutorial slide had this and it worked. It was a mistake in the tutorial as the successor slides add the commas but things make on boggle and wonder). -- J. From kostis@REDACTED Sun Dec 26 19:07:34 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 26 Dec 2010 20:07:34 +0200 Subject: no_file:none confusing warning message Message-ID: <4D178466.70104@cs.ntua.gr> An Erlang/OTP user sent me some code to investigate a warning from the compiler that he could not locate (in a 1500 line file). I've minimized it to an an appropriate test case and include it here: %---------------------------------------------------- -module(no_file_none_warning). -export([test/1]). test(Bs) -> [{B, ok} = {B, foo:bar(B)} || B <- Bs], ok. %----------------------------------------------------- Compiling it produces: % erlc no_file_none_warning.erl no_file:none: Warning: a term is constructed, but never used The warning is confusing for various reasons: first of all it mentions neither the file name nor the line it occurs, but it would have been confusing even if it did because one would not know whether it refers to the {B, ok} terms or to the result of the list comprehension. Kostis From robert.virding@REDACTED Sun Dec 26 22:26:33 2010 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 26 Dec 2010 21:26:33 +0000 (GMT) Subject: [erlang-bugs] Parser error regression for ERTS V5.8.3 In-Reply-To: <13180830.232841293398504562.JavaMail.root@zimbra> Message-ID: <1385937741.232861293398793536.JavaMail.root@zimbra> This is not a bug, it's a feature. Unfortunately. As you have noted it is a result of the syntax change which allowed nested record access without parentheses. But it is not an error as the parse is correct. What confuses the issue is that it is spread over three lines and that missing commas have exposed it. If you read it as: #foo(bar=1}#foo{bar=2}#foo{bar=1} it becomes clearer. This is parsed as (with parentheses): ( ( #foo{bar=1} ) #foo{bar=2} ) #foo{bar=3} It then becomes clear that the parse and resultant value are correct and the confusion arises from not having to add parentheses. This usage was probably not intended when the mandatory parentheses were removed by became legal, more as a "by-product". I would support rolling back. Robert P.S. I am trying not to say "vad var det jag sa" (what did I tell you) as one of the reasons I/we added the parentheses was to make it easier for the user and not just the parser. :-) ----- "Jesper Louis Andersen" wrote: > Consider the following module: > > == > -module(foo). > -compile(export_all). > > -record(foo, { bar }). > > > x() -> > [ #foo { bar = 1} > #foo { bar = 2} > #foo { bar = 3}]. > == > > In ERTS V5.8.3 this is valid (notice the lack of commas at the end of > each line). It is also valid in V5.8.1, but it fails on V5.7.4: > > ./foo.erl:9: syntax error before: '#' > ./foo.erl:4: Warning: record foo is unused > > The result of foo:x(). is: > > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.8.3 (abort with ^G) > 1> c(foo). > {ok,foo} > 2> foo:x(). > [{foo,3}] > 3> > > which I find highly confusing and wrong. > > The parse derivation is: expr -> list -> tail -> expr -> record_expr > --(by the last clause erl_parse.yrl L351)--> record_expr .... > > (parse derivation from commit 609e7ade98c) > > git annotate lib/stdlib/src/erl_parse.yrl points to commit 3829e5fa > ..: > > Support nested record field access without parentheses. > ... (omitted rest of the commit) > > git show 3829e5fa > > So it has to do with the introduction of nested records without > parenthesis. I suggest to revert the patch and add something like the > above as a SHOULD_FAIL test case to the parser tests. > > (We found it on the IRC channel because someone asked why a Nitrogen > tutorial slide had this and it worked. It was a mistake in the > tutorial as the successor slides add the commas but things make on > boggle and wonder). > > -- > J. > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED From kostis@REDACTED Wed Dec 29 10:24:54 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 29 Dec 2010 11:24:54 +0200 Subject: ssl:ssl_accept/1 discrepancy in spec and doc Message-ID: <4D1AFE66.60904@cs.ntua.gr> ssl's published documentation states: ssl_accept(ListenSocket) -> ssl_accept(ListenSocket, Timeout) -> ok | {error, Reason} (see http://www.erlang.org/doc/man/ssl.html#ssl_accept-1) while its code has the specs: -spec ssl_accept(#sslsocket{}) -> {ok, #sslsocket{}} | {error, reason()}. -spec ssl_accept(#sslsocket{}, list() | timeout()) -> {ok, #sslsocket{}} | {error, reason()}. One of the two cannot be right. This should be fixed. Moreover, I do not see why the spec just mentions list() for the options when the documentation explicitly mentions the options of ssl. Kostis