http://blog.gmane.org/gmane.comp.lib.ev hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.ev/2146 <pre> By specifying -g in the compiler flags. If you don't embed it, you can e.g.: ./configure CFLAGS=-g </pre> Marc Lehmann 2013-04-16T08:53:56 http://permalink.gmane.org/gmane.comp.lib.ev/2145 <pre>Ok, I will try....thx......this seems to be a challange to me... How to compile libev with -g? i saw some variable was optimized out... 在 2013-04-16 16:27:29，"Marc Lehmann" &lt;schmorp&lt; at &gt;schmorp.de&gt; 写道： _______________________________________________ libev mailing list libev&lt; at &gt;lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</pre> 马承珂 2013-04-16T08:45:02 http://permalink.gmane.org/gmane.comp.lib.ev/2144 <pre> well, I guess somebody has to debug that program to find the bug then. </pre> Marc Lehmann 2013-04-16T08:27:29 http://permalink.gmane.org/gmane.comp.lib.ev/2143 <pre>It runs well with libev-4.04. I am using Scientific Linux release 6.3. Some infomation: [root&lt; at &gt;r210-4g-03 lib]# uname -a Linux r210-4g-03.localdomain 2.6.32-279.19.1.el6.x86_64 #1 SMP Tue Dec 18 17:22:54 CST 2012 x86_64 x86_64 x86_64 GNU/Linux [root&lt; at &gt;r210-4g-03 lib]# gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) (gdb) bt #0 0x0000003e6f075a35 in malloc_consolidate () from /lib64/libc.so.6 #1 0x0000003e6f078bb5 in _int_malloc () from /lib64/libc.so.6 #2 0x0000003e6f07b1ba in _int_realloc () from /lib64/libc.so.6 #3 0x0000003e6f07b4d5 in realloc () from /lib64/libc.so.6 #4 0x00007fc038da96ea in ev_realloc (ptr=&lt;value optimized out&gt;, size=1504) at ev.c:1441 #5 0x00007fc038dabc1c in ev_timer_start (loop=0x7fc038fb1d40, w=0x1ebba70) at ev.c:3593 #6 0x000000000041968c in svr_timer::start (this=0x1ebba68) at ../../fsi_svr_lib/svr/svr_timer.h:53 #7 0x00000000004196b2 in svr_timer::reset (this=0x1ebba68) at ../../fsi_svr_lib/svr/svr_timer.h:56 #8 0x000000000044e53e in inr_crypted_clt::on_connected (this=0x1ebb6f0) at inr_clt.cpp:465 #9 0x0000000000460292 in svr_tcp_client_on_connect (sock=0x1ebb700, result=0) at svr_tcp_client.cpp:35 #10 0x0000000000466c48 in svr_tcp_sock::_on_connect (this=0x1ebb700, events=2) at svr_tcp_sock.cpp:77 #11 0x0000000000466a08 in svr_tcp_sock_on_connect (watcher=0x1ebb748, events=2) at svr_tcp_sock.cpp:16 #12 0x00007fc038da92bd in ev_invoke_pending (loop=0x7fc038fb1d40) at ev.c:2994 #13 0x00007fc038dadad2 in ev_run (loop=0x7fc038fb1d40, flags=&lt;value optimized out&gt;) at ev.c:3394 #14 0x000000000045f030 in svr_common_loop () at svr_global.cpp:132 #15 0x000000000040756b in main (argc=1, argv=0x7fffbf83f6d8) at conn_svr.cpp:294 _______________________________________________ libev mailing list libev&lt; at &gt;lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</pre> 马承珂 2013-04-16T08:11:13 http://permalink.gmane.org/gmane.comp.lib.ev/2142 <pre> No, this is just a (harmless) bug in valgrind, which apparently doesn't recognise the lock prefix correctly, or somesuch. It doesn't affect correctness inside and outside of valgrind. </pre> Marc Lehmann 2013-04-13T16:38:56 http://permalink.gmane.org/gmane.comp.lib.ev/2141 <pre>Hi there, I'm getting some valgrind hits from libev-4.15. It's always with the ECB_MEMORY_FENCE macro. I've checked both AMD64 and i386, the hits occur on the i386 version only. This memory fencing stuff is beyond my knowledge. Is this something to worry about? Thanks ==24105== Invalid read of size 1 ==24105== at 0x805A0DD: ev_run (ev.c:3311) ==24105== by 0x804B755: main (ev.h:820) ==24105== Address 0xfe89e61f is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==24105== ==24105== Invalid read of size 1 ==24105== at 0x80563FF: ev_sighandler (ev.c:2135) ==24105== by 0x6B88287: ??? (in /lib/i386-linux-gnu/libc-2.15.so) ==24105== Address 0xfe89debf is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==24105== ==24105== Invalid read of size 1 ==24105== at 0x8056425: ev_sighandler (ev.c:2145) ==24105== by 0x6B88287: ??? (in /lib/i386-linux-gnu/libc-2.15.so) ==24105== Address 0xfe89debf is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==24105== ==24105== Invalid read of size 1 ==24105== at 0x8056DCD: pipecb (ev.c:2214) ==24105== by 0x8055F0F: ev_invoke_pending (ev.c:2994) ==24105== by 0x805A72F: ev_run (ev.c:3394) ==24105== by 0x804B755: main (ev.h:820) ==24105== Address 0xfe89e5cf is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==24105== ==24105== Invalid read of size 1 ==24105== at 0x8056DE7: pipecb (ev.c:2221) ==24105== by 0x8055F0F: ev_invoke_pending (ev.c:2994) ==24105== by 0x805A72F: ev_run (ev.c:3394) ==24105== by 0x804B755: main (ev.h:820) ==24105== Address 0xfe89e5cf is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==24105== </pre> Matthias Moeller 2013-04-13T12:29:00 http://permalink.gmane.org/gmane.comp.lib.ev/2140 <pre> And what is this "BSD" thing? libev obviously works quite fine on BSDs, so you can't mean that. Sweeping and non-refutable (because they lack substance) statements like yours are dangerously close to trolling. It's not appreciated, so back up, or shut up. </pre> Marc Lehmann 2013-04-05T10:02:06 http://permalink.gmane.org/gmane.comp.lib.ev/2139 <pre>I was talking about watching a directory for changes. Using libevent on BSD, I can get notified, when a directory is accessed or modified. I can not do the same with libev, evidently, which makes it worse (in this particular regard) than libevent. Well, "trolling" was what Tony engaged in, when he posted the above-quoted line </pre> Mikhail T. 2013-04-05T16:40:22 http://permalink.gmane.org/gmane.comp.lib.ev/2138 <pre>Well, looking back, I can see, what could've been misread to mean, what you quoted: On Thu, Apr 04, 2013 at 08:25:24PM -0400, "Mikhail T."&lt;mi+thun&lt; at &gt;aldan.algebra.com&gt; wrote: Thrown off by Tony's inflammatory remark, I was not careful with my own choice of words. I was referring to my test-program, which was able to discern directory-changes on BSD, when using libevent, but not when using libev. The same libevent-using method was not working on Linux, which made it "worthless" in Tony's educated opinion, and I pointed out, libev can not be used for the purpose even on BSD (can it?) -- which would make the method even more "worthless" in the same opinion... -mi _______________________________________________ libev mailing list libev&lt; at &gt;lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</pre> Mikhail T. 2013-04-05T17:20:09 http://permalink.gmane.org/gmane.comp.lib.ev/2137 <pre> Bullshit. Libev gives you I/O readyness notificataions as defined by POSIX. All you have shown is that libevent, when you use edge triggering, fundamentally changes behaviour by not providing those anymore. It's also quite likely that libevent will _not_ change behaviour when it isn't using kqueue as backend, so the behaviour you see isn't even guaranteed by libevent, it is simply spurious. That's simply a bug in libevent that libev does not have. Now, I am not terribly fazed by this bug, as most likely, this is simply a bug in kqueue itself that breaks ddirectory fds when edge triggering is used. Saying libev "does not work on BSD" just means that you don't have a clue what it is supposed to do, you don't have a clue how I/O readyness works, and you didn't care to read the documentation of libev. That's pretty lame for somebody who wants to be taken seriously. But are you? I agree that his comment was pointless. However, it's you who started it: You came here with vague claims about problems, and when explained that there aren't any, you continued with vague accusations of problems, and when told that you need to explain yourself, you just kept quite instead of clarifying. I am still waiting for an explanation, but I am not holding my breath. This is why I can tolerate Tony's comment, but not yours. You shouldnÄt be surprised if people treat you like you treat other people. That's just more FUD. You have been told that the warning is spurious. It's at best a bug in your compiler, except that GCC doesn't claim that its warnings are perfect, so it isn't even a bug in GCC. Now, since you are so full of yourself, care to explain what libev should do to silence the warning? The code is correct, after all. And all you have shown so far is that you don't even understand what the compiler warning says. But, again, I am not holding my breath waiting for an explanation. One troll less it seems. </pre> Marc Lehmann 2013-04-05T16:59:52 http://permalink.gmane.org/gmane.comp.lib.ev/2136 <pre> No, you are just full of air - you never answer the question and how you think it could be fixed to your liking, you just repeat that something unspecified needs to be done, and ignroe the question on what that would be. It's hard to agree or disagree with somebody who doesn't even have a position to agree or disagree with, so no, you don't disagree, you are just avoiding any explanations that would show that you you were wrong, or don't even know what you are talking about. You ask for improvements without even explaining what these improvements actually are, even though being asked repeatedly and specifically what should be done to avoid the problem you are making up. It's obvious you are just trying to provoke people, as you have nothing whatsoever of substance to say. </pre> Marc Lehmann 2013-04-05T19:58:35 http://permalink.gmane.org/gmane.comp.lib.ev/2135 <pre> Now you are trolling, because here is a direct quote, not taken out of context: Message-ID: &lt;515E19F4.7050804&lt; at &gt;aldan.algebra.com&gt; "libev does not even work on BSD" So yes, Mikhail, you didn't say that, you wrote that. Now saying you didn't is dishonest - or are you claiming that mail came from an imposter, or that my quote was out of context? And do you even understand the difference between a literal quote and paraphrasing? I think you do understand. I am still waiting for any explanation of your claims, but it looks as if you can't, and instead resort to classical trolling behaviour of "I never said that" and using ad hominems to hide the lack of arguments on your side. You know very well that your comment was only designed to waste more of my and other people's time by looking up the mail where you said that. If you want me to change something for you, you do. And you certainly said you wanted me to change it. So yes, you need to convince me. You failed. I do care, but since the only place where this warning can be fixed is in the compiler, caring is not enough. If you disagree with that, you had ample time to explain what the problem is, or how you think it could be fixed. However, I am just repeating myself, and you arejust trying to burn time. Since by now, it is obviously clear that you are only interested in wasting time and not in a honest discussion, the discussion with you ends here until you improve considerably. </pre> Marc Lehmann 2013-04-05T17:47:07 http://permalink.gmane.org/gmane.comp.lib.ev/2134 <pre> Look, libev is a library that, in my opinion, is known for one thing in particular: excellent cross-platform abstractions that provide the same semantics across multiple operating systems. I don't think it makes sense to include a feature that only works on FreeBSD in libev. </pre> Tony Arcieri 2013-04-06T01:26:36 http://permalink.gmane.org/gmane.comp.lib.ev/2133 <pre>You are way too angry to be taken seriously, Marc. I never said, what you put into quotes. Never ever. As for compiler warnings, I don't need to convince you of anything. /I/ would think thrice about using a library, whose header file triggers warnings from the OS' base compiler,//but if you don't care, who am I to tell you otherwise more than I already did? -mi _______________________________________________ libev mailing list libev&lt; at &gt;lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</pre> Mikhail T. 2013-04-05T17:06:19 http://permalink.gmane.org/gmane.comp.lib.ev/2132 <pre> Of course I didn't misread anything. You didn't refer to your test program, you refered explicitly to libev, by even mentioning its name in that sentence. You might have *meant* something else, but you didn't write that. You are responsible for what you say, not others. And as I told you, it doesn't work with libevent either when not using a specific backend, what you are hitting is likely a bug. Repeating bullshit to make it fly won't make it so. </pre> Marc Lehmann 2013-04-05T17:52:06 http://permalink.gmane.org/gmane.comp.lib.ev/2131 <pre> Are you using a custom client or something like netcat? How is recv failing? Your (stripped down) program is unsafe: Try sending a string of 1024 non-null characters to it. :-) HTH, JOnathan Neuschäfer _______________________________________________ libev mailing list libev&lt; at &gt;lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</pre> Jonathan Neuschäfer 2013-04-06T05:33:10 http://permalink.gmane.org/gmane.comp.lib.ev/2130 <pre>Compiler warning is THE problem, and blaming the compiler is just funny. Even if compiler was at fault in a particular case, the supposedly spurious warning should be quieted down so that other warnings will be noticed the second they appear. So, yes, I do disagree. I've already spent some time explaining, as you point out, but because libev is not doing what I need, I will not be using it (until it improves considerably), so I will certainly not be spending any /more/ time explaining, what to me is perfectly obvious already. -mi _______________________________________________ libev mailing list libev&lt; at &gt;lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</pre> Mikhail T. 2013-04-05T17:57:49 http://permalink.gmane.org/gmane.comp.lib.ev/2129 <pre>For implementing realtime reports I have written a custome libev server .. that runs on a socket and "listens" to reports sent. The code runs in 2 threads , one thread simply listens for the data and pushes into a shared memory. The other thread updates the data into a mysql db Code seems to run fine most times , but sporadically the clients connecting to the server are not able to recv() from the server. The servers sends using send() which returns fine , but the client gets nothing. The stripped down version of the server code is here http://pastebin.com/SM7uPkVD Can someone help point out if there are some obvious things I missed. I am beginner at socket programming in C </pre> Ram 2013-04-05T04:50:59 http://permalink.gmane.org/gmane.comp.lib.ev/2128 <pre> Huh, what? Since when does libev not work on BSD? _______________________________________________ libev mailing list libev&lt; at &gt;lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</pre> Jann Horn 2013-04-05T00:27:25 http://permalink.gmane.org/gmane.comp.lib.ev/2127 <pre>04.04.2013 16:08, Tony Arcieri ???????(??): It does not... Which, I suppose, makes it only slightly less useless that libev. Because libev does not even work on BSD. -mi _______________________________________________ libev mailing list libev&lt; at &gt;lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</pre> Mikhail T. 2013-04-05T00:25:24 http://permalink.gmane.org/gmane.comp.lib.ev/2126 <pre> libev does, but within the limitations of portability. for example, there doesn't seem to be a way to implement ev_stat watchers with kqueue, and inotify can only provide hints in some cases (inotify is use by libev for this). however, the end result is really the same on all platforms, that is, changes can be missed when they are happening fast, and this is still the best that is apparently possible, even on systems with inotify and kqueue. Which might mean it is buggy, or is written in a style that requires it. For example, it might not compile with libve or glib, but neither of that menas that EV_ET is required for directory change detection. It's up to you to explain the connection between the two. Looking at your program in more detail, it seems to be simply buggy, and will probably not even work with libevent on freebsd, depending on which backend is used. See ev_stat watchers. Not reliably - you can use an ev_stat watcher to see if the mtime changes, and then scan for new file names, which might work well enough for your use case. Inotify can give you the name directly, but whether "new filename" means the same thing as "new file" is another question :) </pre> Marc Lehmann 2013-04-04T21:09:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.ev