Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2015-10-04

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:57 bulk88 joined #perl11
02:30 bulk88 joined #perl11
04:16 bulk88 joined #perl11
06:17 bulk88 joined #perl11
06:25 rurban joined #perl11
06:51 sten1 rurban, I mean huge count of NULL SVs, not huge value. I just found this leak in Coro::EV, but it was hard. I used PERL_MEM_LOG, Internals::DumpArenas, Devel::FinfdRef and something more.. but this doesn't help to find leaks in XS
06:53 sten1 Internals::DumpArenas still segfault under 5.20.2: http://pastebin.com/CRq6qy0Q
07:40 bulk88 rurban, I dont think I have such a branch on my remote https://github.com/bulk88/cperl/branches/all https://github.com/bulk88/cperl/tags , I deleted nearly all of your branches on my remote to reduce clutter
07:41 bulk88 sten1 DEBUG_LEAKING_SCALARS+C debugger
07:42 bulk88 DEBUG_LEAKING_SCALARS records the creation point of every SV
07:49 sten1 bulk88 I just tried - it didn't see leaking. this is a testcase: http://pastebin.com/xYrn9bxP
07:50 bulk88 unless you are creatign circular references, you can't debug SV leaks from PP
07:50 bulk88 you must obtain a call stack of where it was allocated to debug it
07:50 bulk88 *C callstack
07:51 sten1 but how to obtain where it was allocated?
07:51 sten1 it was is hardest part to reduce testcase
07:52 sten1 PERL_MEM_LOG shows allocations only in SV.c
07:52 bulk88 do you know how to use a C debugger? (console gdb is horrible, use a gui that can step code, I once used Eclipse with GDB)
07:54 bulk88 PERL_MEM_LOG is for malloc leaks (malloc blocks exist only in 2 states, allocated and free/unallocated), not SV * leaks where are refcount orianted
07:55 sten1 it shows SV allocations with PERL_MEM_LOG=s
07:55 bulk88 where was the SV * created? where was it ++ed? what "owns" the SV*? how is the SV* reachable? where is its parent and point with your finger to the C struct member in the parent that has the SV *
07:56 rurban bulk88:: thanks
07:57 bulk88 a SV* can be owned inside another SV (RV), a HV, a AV, on a pad that lives under a CV, the SV * can be owned by the mortal stack, or the save stack, in no thread buuilds a SV * can be owned by an OP struct
07:57 bulk88 an SV* can be owned by a MG *
07:57 rurban sten: Those NULL SVs are usually no leaks. They have to be there. But -DDEBUG_LEAKING_SCALARS helps
07:58 sten1 yes, but in my case NULL SVs is unowned
07:58 rurban You said they are PADTMP, so they are owned by some padlist
07:59 sten1 it was my mistake, I rechek dump and SVs leaking was without this flag
08:00 rurban Maybe Coro::EV leaks
08:00 sten1 yes, it leaks, this is a testcase http://pastebin.com/xYrn9bxP
08:01 sten1 I already wrote to schmorp. but my question is how to determine mem leaks like this in big apps
08:01 rurban Then you need to talk to schmorp. He for sure wants to get rid of leaks.
08:01 sten1 I spend around 2 weeks to produce this testcase :)
08:01 bulk88 rebuild with DEBUG_LEAKING_SCALARS and dumping the sv with D::Peek or a similar tool, then a line "ALLOCATED at %s:%d %s %s (parent 0x%"UVxf"); serial %"UVuf"\n" will say where that SV* cam efrom
08:02 rurban That's not easy at all. But with DEBUG_LEAKING_SCALARS the SV in question has the information. Problem is: Internals::DumpArenas does not print it yet
08:02 rurban yes, the ALLOCATED line should help
08:03 rurban good testcase
08:13 sten1 omg, D_L_S + DumpArenas is what I'm looking for, thanks!
08:13 sten1 rurban can you check also Internals::DumpArenas for 5.20? it still segfault
08:13 rurban To find the actual leak schmorp is the best. Only he knowns Coro and EV. Some innocent XS usually
08:14 rurban Oh. interesting. Which testcase?
08:14 rurban can file an issue please?
08:14 sten1 http://pastebin.com/CRq6qy0Q
08:14 rurban can you...
08:15 sten1 seems like it is impossible to create issue in your fork
08:15 rurban yep, can repro it with threads
08:17 sten1 my perl w\o threads: (v5.20.2) built for darwin-2level
08:17 rurban Again a SvSTASH as 0x18. So it's not only %version::
08:17 rurban Now it's %File::
08:18 rurban That's a core bug btw. Should be perlbug'ged
08:19 rurban Maybe it's the OVERLOAD, which corrupts the stash. %version:: also has OVERLOAD
08:22 rurban I filed it for me at https://github.com/perl11/cperl/issues/60
09:25 rurban1 joined #perl11
09:43 rurban joined #perl11
10:19 stephen joined #perl11
10:36 basiliscos joined #perl11
13:02 j0e joined #perl11
16:47 stephen joined #perl11
18:15 travis-ci perl11/cperl#275 (bugfix/gh61-config+1 - 1097d2a : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/83578303
19:52 travis-ci perl11/cperl#276 (bugfix/gh61-config+1 - caa1b0a : Reini Urban): The build was broken. https://travis-ci.org/perl11/cperl/builds/83590954
20:21 travis-ci perl11/cperl#277 (bugfix/gh61-config+1 - 6c56511 : Reini Urban): The build was fixed. https://travis-ci.org/perl11/cperl/builds/83592425
20:43 travis-ci perl11/cperl#278 (master - 6c56511 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/83595456
21:06 travis-ci perl11/cperl#279 (bugfix/gh44-appveyor - f8647f2 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/83596193
21:27 travis-ci perl11/cperl#280 (bugfix/CM-891-rt123878-goto-die - b02c1f8 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/83596204
21:39 travis-ci perl11/cperl#282 (bugfix/gh26-qw-as-parens - 9fd9b80 : Reini Urban): The build is still failing. https://travis-ci.org/perl11/cperl/builds/83596232
21:48 travis-ci perl11/cperl#281 (bugfix/gh59-dump - ad3a388 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/83596217
21:49 travis-ci perl11/cperl#283 (bugfix/gh8-cowrefcnt - 3f71879 : Reini Urban): The build is still failing. https://travis-ci.org/perl11/cperl/builds/83596267

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary