[okular] [Bug 398443] okular sometimes goes into a state where "space" is recognized for navigation, but not "delete" or "pageup/pagedown"
https://bugs.kde.org/show_bug.cgi?id=398443 --- Comment #3 from Frederick Eaton --- Yes indeed, that does the trick. Thank you. I must have missed it before. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398442] New: okular doesn't respect page reverse setting of PPD or lpadmin
https://bugs.kde.org/show_bug.cgi?id=398442 Bug ID: 398442 Summary: okular doesn't respect page reverse setting of PPD or lpadmin Product: okular Version: 1.5.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: printing Assignee: okular-de...@kde.org Reporter: frede...@ofb.net Target Milestone: --- See this bug: https://github.com/OpenPrinting/cups-filters/issues/47 and here: https://github.com/apple/cups/issues/5315 I wrote: > Okular fails to respect the "reverse" setting in the PPD. You have to > manually check the "reverse" button each time. But xpdf, which has the same > print dialog and also seems based on qt5, lacks this problem. I couldn't find > any documentation of the correct behavior. The problem is that when printing documents on an inkjet printer, I would like to be able to pick up the document and staple it without manually reversing the pages first. But that means having the pages come out in reverse order, since the printer is printing face-up. There are settings in the PPD and in other CUPS tools which allow me to specify that pages should be reversed by default. However, Okular seems to be ignoring these settings. Unless I check the "reverse" box in the print dialog, pages come out in the wrong order on my inkjet. Some things were fixed in cups-filters but I find that the bug persists, so I'm letting the Okular team know about it. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398443] New: okular sometimes goes into a state where "space" is recognized for navigation, but not "delete" or "pageup/pagedown"
https://bugs.kde.org/show_bug.cgi?id=398443 Bug ID: 398443 Summary: okular sometimes goes into a state where "space" is recognized for navigation, but not "delete" or "pageup/pagedown" Product: okular Version: 1.5.1 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: frede...@ofb.net Target Milestone: --- I've experienced this problem for a while now. Randomly, I'll open a PDF document, say via a text-based web browser, in Okular. I'll use "space" or the mouse wheel to navigate down the document. However, when I hit "delete" the keypress is ignored. Same with "pageup" and "pagedown" - ignored. But if I use the mouse and click on the document, then it fixes things and I can navigate with these keys again. Unfortunately I haven't found a way to reproduce this. It happens every day, but it may be dependent on a race condition or something because I can't make it happen on demand. Maybe I am doing a particular thing without realizing it, e.g. starting to type before the document comes up. Or maybe it only happens on new documents that Okular hasn't seen before. Usually when I open a document, all keys work for navigation at startup. I use the i3 window manager and the w3m web browser. I'm not sure if the bug is dependent on opening a document with w3m. I know this isn't much to go on but I wanted to submit here because I'm not making any progress on getting more information, and I thought maybe somebody familiar with the code of Okular could say what is happening. It seems that something is going on related to focus. Is there a focus state where Okular responds to "space" but not "delete" for navigation? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398443] okular sometimes goes into a state where "space" is recognized for navigation, but not "delete" or "pageup/pagedown"
https://bugs.kde.org/show_bug.cgi?id=398443 Frederick Eaton changed: What|Removed |Added CC||frede...@ofb.net --- Comment #1 from Frederick Eaton --- I realized on further observation that this seems related to Okular's on-demand loading of PDF data. Sometimes when Okular is open in a tab, I can cause it to enter a bad-focus state just by scrolling down in a recently-opened document. In other words, it'll be in a state where "space" and "delete" both work; then I press "space" several times and Okular pauses a second while loading the next page, and then I find that it no longer recognizes "delete" to scroll up... and I have to use the mouse button to restore focus. So you can probably ignore the information about my window manager, and certainly my web browser, in the initial report; the bug can be triggered entirely within Okular. By the way how do I get a list of bugs I've submitted? The "My Requests" link in the header doesn't show anything... -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398442] okular doesn't respect page reverse setting of PPD or lpadmin
https://bugs.kde.org/show_bug.cgi?id=398442 --- Comment #2 from Frederick Eaton --- $ pacman -Q qt5-base qt5-base 5.11.1-2 Steps: 1. Configure a printer to reverse pages (using PPD or lpadmin) 2. Print something in Okular 3. The pages come out non-reversed. I would have expected them to be reversed According to my bug report, I was able to get pages to reverse / not reverse using the Virtual_PDF_Printer which is part of the cups-pdf package. This provided an easy way to confirm the bug. However, I was not able to do that in the recent version, perhaps when Till Kamppeter updated cups-filters it changed something related to this behavior. Now all "reverse" settings, even in the print dialog, are ignored by Virtual_PDF_Printer, in all clients. In fact, after I just upgraded, normal printing seems to be broken on the server I used to print. But before upgrading I was able to confirm that Okular ignores the lpadmin and PPD settings when printing on paper. I would suggest trying to debug using Virtual_PDF_Printer, if you can reproduce the bug there, then you can save paper. You can use lpadmin to control the outputorder settings: lpadmin -p Virtual_PDF_Printer -o outputorder-default=reverse lpadmin -p Virtual_PDF_Printer -R outputorder-default Apparently this causes a line to be added to /etc/cups/printers.conf, although I can't find any documentation of this fact: $ lpadmin -p HP_Photosmart_Plus_B210_series -o outputorder-default=reverse $ sudo systemctl restart org.cups.cupsd.service $ sudo grep outputorder /etc/cups/printers.conf Option outputorder reverse $ lpadmin -p HP_Photosmart_Plus_B210_series -R outputorder-default $ sudo systemctl restart org.cups.cupsd.service $ sudo grep outputorder /etc/cups/printers.conf [1]$ Otherwise, as I said in the report, adding a line to the ppd should work as well: $ sudo grep -i defaultoutput /etc/cups/ppd/HP_Photosmart_Plus_B210_series.ppd *DefaultOutputOrder: "reverse" In both cases the setting was respected by evince and other utilities, but not okular. Till Kamppeter suggests it should be: *DefaultOutputOrder: Reverse I'm not sure if that fixes things for Okular, but I would doubt it, as controlling the setting via lpadmin also didn't work. Obviously you don't want to comment out the PPD line after you add it. If it was commented out in the PPD I uploaded, that was probably a reflection of the state of the file at the time I was trying various settings. A lot of my original bug was about lack of documentation, so good luck. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398442] okular doesn't respect page reverse setting of PPD or lpadmin
https://bugs.kde.org/show_bug.cgi?id=398442 Frederick Eaton changed: What|Removed |Added CC||frede...@ofb.net -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398442] okular doesn't respect page reverse setting of PPD or lpadmin
https://bugs.kde.org/show_bug.cgi?id=398442 --- Comment #3 from Frederick Eaton --- After a full system upgrade (to fix printing), I confirmed that the bug still exists. This is for printing on paper, and configuring reversal using 'lpadmin' (i.e. printers.conf). Evince reverses, Okular doesn't. I'll be happy to hear what results other users get when they try this. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398442] okular doesn't respect page reverse setting of PPD or lpadmin
https://bugs.kde.org/show_bug.cgi?id=398442 --- Comment #4 from Frederick Eaton --- Also I can again reproduce this with cups-pdf, so you don't need a printer. 1. Install cups-pdf 2. Add a printer via the CUPS interface, and select CUPS-PDF 3. Select the cups-pdf PPD /usr/share/cups/model/CUPS-PDF_opt.ppd 4. Use lpadmin to configure page reversal: lpadmin -p Virtual_PDF_Printer -o outputorder-default=reverse 5. Print a multi-page document using Okular to Virtual_PDF_Printer 6. Check the cups-pdf spool, something like: /var/spool/cups-pdf/frederik/t.pdf_pool_cups-pdf_frederik-job_61.pdf The pages are not reversed. 7. Try printing the same document with lp and evince $ lp -dVirtual_PDF_Printer t.pdf request id is Virtual_PDF_Printer-62 (1 file(s)) # check the pages are reversed in /var/spool/cups-pdf/frederik/*job_62.pdf $ evince t.pdf # print to Virtual_PDF_Printer with evince # check pages reversed in /var/spool/cups-pdf/frederik/*job_63.pdf Hope this helps. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398442] okular doesn't respect page reverse setting of PPD or lpadmin
https://bugs.kde.org/show_bug.cgi?id=398442 --- Comment #7 from Frederick Eaton --- > Can you confirm it's also working as you'd expect when you use the "Force > rasterization" option in the print dialog? Yes. Some observations: - What does "force rasterization" mean? It's not really self-explanatory. Does anyone use it? - If I check an "Options >>" option in the print dialog, the next time I open the dialog it is unchecked. Which is fine because usually I'm selecting a page range or number of copies or something that I want to only do for one document. As a user I would expect the "Reverse" setting in this place to apply to just one document as well, not to the printer in general. In other words it should produce a document whose pages are backwards when I take it out of the printer and try to staple them. To accomplish this, you wouldn't override the "output-order" setting of CUPS. Rather you would modulate it, as in exclusive-OR: "print dialog options = reverse" + "default output order = reverse" -> "setting for this job = normal". But I think that CUPS should be doing that automatically, even when the output order setting is specified on the command line, it should modulate and not override. I don't see the utility of allowing client applications to override printer-specific details like this, it breaks the abstraction layer that CUPS is supposed to provide. Why should Okular need to know whether my printer prints face-up or face-down? Why should it *get* to know? Unfortunately I was not able to communicate this to the CUPS maintainer before he closed my bug as "too heated". YMMV. You may want to look at how other KDE applications do printing, I seem to recall finding one which did not have this problem, but I can't remember for sure and I didn't find it when looking over the various bug reports I made. Or you could look at Evince and other GTK applications. It would probably be useful if you were able to reproduce this yourself. I have provided instructions for how to do that without a printer, did you run into problems following them? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398442] okular doesn't respect page reverse setting of PPD or lpadmin
https://bugs.kde.org/show_bug.cgi?id=398442 --- Comment #9 from Frederick Eaton --- Thanks Michael for clarifying that you can reproduce the bug. > In the end, the processing is done by CUPS (or the CUPS filters > involved) according to the "outputorder" CUPS option. Okular does > not reverse the pages itself, only passes the respective option to > CUPS according to whether the checkbox is ticked or not. I figured this out already, and I think this is the wrong way to do it. It makes sense for "Duplex"; not for "Reverse". Please take a minute to look at the Evince print dialog. There is an area for specifying page ranges, number of copies, and page reversal. As you can see from this 2006 commit, Evince implements page reversal by sending pages to the spooler in reverse order: https://gitlab.gnome.org/GNOME/evince/commit/e15ce77fdce11d47bc92a209efb013c008d502d5 In the GTK dialog there is also a separate "Page Setup" tab which has options for stuff like "Output tray" as well as "Two-sided" and ... "Page ordering"! In other words, Evince and other GTK apps let you configure output-order separately from the main "Reverse" option. The "Output tray", "Two-sided", "Page ordering", etc. are CUPS/lp options, and the dialog takes their defaults from ~/.cups/lpoptions, if they exist there, but the dialog (which is probably a bug...) ignores the defaults specified in OpenUI blocks in the PPD: *%=== Duplex *OpenUI *Duplex: PickOne *OrderDependency: 25 AnySetup *Duplex *DefaultDuplex: DuplexTumble *Duplex DuplexTumble: " " *Duplex DuplexNoTumble: " " *Duplex None: " " *CloseUI: *Duplex When I tested it, Okular ignores both sources of defaults (PPD and lpoptions), although it does correctly recognize that a non-duplex printer should have the duplex radio buttons disabled. (By the way, if I owned a duplex printer, how would I tell Okular to turn on duplexing by default? With GTK I have to specify this with 'lpoptions', how do KDE users do it?) Rather than putting the page ordering under the "Options" tab with "Duplex Printing", like GTK does, Okular/KDE calls it "Reverse" and puts it in a "Copies" tab together with stuff like "Print range" and number of copies. These are all things which can be configured at the client side of the print-stream, as a filtering or pre-processing step, unlike options such as "Duplex", resolution, quality, etc. It would be confusing to give one of them a printer-dependent default. Since 'lp' also allows you to select the page range for a document, number of copies, etc., I thought it would make sense for CUPS to add a "page-order" lp option to supplement the "output-order" lp option. The "output-order" would control the temporal ordering of the pages - which comes out of the printer first - while "page-order" would control the order of the pages within the finished document, via a filtering/preprocessing step just like "page-ranges" - for those rare cases where someone wants a document with the pages actually reversed. This would make your life easier, but I doubt that Apple is willing to add new features to CUPS to make life easier for Linux programmers, particularly as I am not actually able to think of a strong case where someone would want to print a document with pages going backwards. Maybe one solution you could consider is just removing the "Reverse" option from the dialog and the software. This would fix your software for the 70% of people who use inkjets [*], at the expense of the (hypothetical) <0.1% of people who read documents in reverse. But I guess you'd have to implement that change in Qt/KDE since the dialog comes from there. Or you could just ignore the dialog's "Reverse" setting, while leaving the checkbox there to potentially confuse the 0.1%. [*] http://news.printcountry.com/2010/04/inkjet-vs-laser-printer-market-share-and-statistics.html Anyway, your proposal requires querying CUPS to find the default page-order setting in the PPD and in printers.conf/lpadmin. Given that neither Okular nor Evince know how to correctly query the default "duplex" setting from the PPD, and given that Duplex has an OpenUI/CloseUI block in the PPD while there is nothing like this for the output-order setting (at least not in the default PPD I got from cups-filters), I think you will run into technical obstacles. And given that the Okular devs have been seemingly oblivious to the fact that inkjet printers output pages in a different order than laserjets for - what, over a decade? - I'm doubting your logic that end users wou
[okular] [Bug 398442] okular doesn't respect page reverse setting of PPD or lpadmin
https://bugs.kde.org/show_bug.cgi?id=398442 --- Comment #10 from Frederick Eaton --- Here is where I got the data about ~/.cups/lpoptions: https://askubuntu.com/questions/339607/why-dont-applications-respect-a-printers-default-options -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 384695] Configurable horizontal scrolling key (ALT or SHIFT) + WHEEL
https://bugs.kde.org/show_bug.cgi?id=384695 Frederick Eaton changed: What|Removed |Added CC||frede...@ofb.net --- Comment #2 from Frederick Eaton --- I would like to second this. Shift+wheel is what I use in Firefox (with some configuration). I didn't even realize that Alt+wheel is what Okular uses until I saw this bug. I don't understand what Shift+wheel is doing in Okular but it seems not useful - it scrolls diagonally, and rotating the wheel in the opposite direction doesn't return me to where I was. I would expect opposing arrow keys and opposing scroll wheel motions to have opposite effects, that's pretty much a fundamental principle of document navigation. I had just assumed the software was broken. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] New: valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 Bug ID: 366035 Summary: valgrind misses buffer overflow, segfaults in malloc in localtime Product: valgrind Version: 3.11.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: frede...@ofb.net I get the following error when I use Valgrind to debug my buggy program: --433-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --433-- si_code=128; Faulting address: 0x0; sp: 0x802ba9e30 valgrind: the 'impossible' happened: Killed by fatal signal Turns out it was a simple buffer overflow but Valgrind didn't catch it. Since the code is fairly small, I thought it might be useful to submit. I made a tar file with the valgrind output, my code, and the command to run it. You need to run the code on a machine with a sound card. Thanks. Reproducible: Always I hope I get to upload an attachment after clicking "Submit Bug Report"! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #1 from Frederick Eaton --- Created attachment 100267 --> https://bugs.kde.org/attachment.cgi?id=100267&action=edit code and output file You are welcome to critique my coding style. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #2 from Frederick Eaton --- Created attachment 100269 --> https://bugs.kde.org/attachment.cgi?id=100269&action=edit output file only -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 Frederick Eaton changed: What|Removed |Added Attachment #100269|0 |1 is obsolete|| --- Comment #4 from Frederick Eaton --- Created attachment 100308 --> https://bugs.kde.org/attachment.cgi?id=100308&action=edit output file with line numbers in host stacktrace -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #5 from Frederick Eaton --- Created attachment 100309 --> https://bugs.kde.org/attachment.cgi?id=100309&action=edit verbose output -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #6 from Frederick Eaton --- Hi Philippe, Thanks for responding. I'm using Arch Linux, it's weird that the default Arch package is not to your liking. Well I compiled from ABS adding (!strip debug) to OPTIONS in /etc/makepkg.conf, the new version gives line numbers for the backtrace. I attached the new output and also the output with the verbose options you recommended. > E.g. I do not see why the line after #ifndef BUG is needed: this seems to get > the nr of channels that were set just before ??? The program uses libsndfile and libasound (ALSA) as you can see. The ALSA library has elaborate mechanisms to resolve differences between settings that the user might request and restrictions that might be imposed by the hardware device. I should have used the function `snd_pcm_hw_params_set_channels_near` which takes a requested number of channels and returns the actual number assigned. http://alsa-lib.sourcearchive.com/documentation/1.0.8-3/group__PCM__HW__Params_g59aa9e1a02f4ce616fe92c605a833f8f.html#g59aa9e1a02f4ce616fe92c605a833f8f In the original version I just called `snd_pcm_hw_params_set_channels` and assumed the setting had been honored by ALSA. I requested 1 channel, ALSA created 2 channels per device constraints, I allocated space for 32768 1-channel "frames", ALSA return 32768 2-channel frames. I got a buffer overflow. I hope this answers your question. I imagine that my original submission was a bit confusing. The libraries are not too exotic, and although you need a soundcard with stereo inputs to reproduce the bug I imagine that's not such a rarity. However, let me know if the new files I submitted do not resolve the mystery for you, and then I can maybe work on a more minimal test case. Thanks, Frederick -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 Frederick Eaton changed: What|Removed |Added CC||frede...@ofb.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #8 from Frederick Eaton --- > Forcing the channel to 1 at that 'BUG' place has other consequences than just > allocating a 'too small' buffer. > As I understand, after this 'forcing to 1', we will also have > sfinfo.channels that will > be 1 instead of 2. No idea if that participates (or not) to the problem. I don't think it does, sfinfo is just used for the output file, if we give it a smaller number of channels then it will read less data from the buffer. > So, I will assume that this snd_pcm_readi is not doing a read syscall but is > rather > an ioctl, probably corresponding to this trace: > SYSCALL[14734,1](16) sys_ioctl ( 4, 0x80184151, 0xffefff170 ) --> [async] > ... > SYSCALL[14734,1](16) ... [async] --> Success(0x0) > > I am not sure how to translate this 0x80184151 into one of the 'symbolic' > ioctl > SND/PCM things handled in syswrap-linux.c. > I suspect that some SND/PCM ioctl are not properly described as > reading/writing the memory > pointed to by the ARG3 of the ioctl. Then of course, that might do a buffer > overrun > which is undetected by Valgrind, which then corrupts the end of the buffer > block > and the malloc data structure/memory/blocks following this (too small) > buffer. That sounds very likely to be the source of the problem, good detective work! > So, at this point, what we need to confirm is: > is snd_pcm_readi really doing an ioctl ? > if yes, which one ? (i.e. which 'symbolic' ioctl is it doing ?) > e.g. maybe it is case VKI_SOUND_PCM_READ_CHANNELS: > and if this is the case, then syswrap-linux.c describes that this ioctl > is writing the > size of an int, while it clearly reads more than an int, if the ioctl is > reading real data. > If now that is the bug, and syswrap-linux.c really should describe that it > reads a bunch > of bytes depending on previously set parameters, then I think that is a lot > of work to do, > as basically syswrap-linux.c will need to record the previous SND/PCM ioctl > to know what > is the expected size of such an ioctl ARG3. > > Now, maybe this ioctl is rather something like VKI_SNDRV_CTL_IOCTL_TLV_READ > but I do not see how that matches this buffer logic and the snd_pcm_readi, > which only > has a buffer argument. > > So, to understand where the undetected buffer overflow comes from, I guess > some > alsa/snd lib source code reading might be needed, to see how snd_pcm_readi > is implemented > in terms of ioctl. > We can then check if syswrap-linux.c properly describes what this ioctl is > accessing > in read and/or write mode. > > Hoping this helps I hope it helps too! What do you want me to do now? Is there some other tracing facility which I should run to help you identify the problematic ioctl? Do you want me to make the example program more minimal? Perhaps I could do the latter, otherwise I don't really have much time - I just wanted to report this bug as a kind of housekeeping task, so that upstream knows about the problem. We can maybe rename it to something like "valgrind doesn't correctly track buffer overflows from certain ALSA ioctls". Thank you, Frederick -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #10 from Frederick Eaton --- Hi Philippe, Thanks for the suggestions. I'm afraid I don't have time to fix the full bug, and I think whoever updates syswrap-linux.c will want to have a working version of the bug to experiment with, so this is a good place for me to pass it off to the developers. FWIW I tried to create a minimal test case but it didn't work; valgrind caught the buffer overflow: ==19707== Invalid write of size 4 ==19707==at 0x510F183: sync_ptr1.isra.7 (pcm_hw.c:134) ==19707==by 0x51109CB: sync_ptr (pcm_hw.c:146) ==19707==by 0x51109CB: snd_pcm_hw_readi (pcm_hw.c:837) ==19707==by 0x40123B: main (minimal.cpp:83) I'm attaching the archive with minimal test case included. Good luck, Frederick -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 Frederick Eaton changed: What|Removed |Added Attachment #100267|0 |1 is obsolete|| --- Comment #11 from Frederick Eaton --- Created attachment 100360 --> https://bugs.kde.org/attachment.cgi?id=100360&action=edit code and output file with (not-working) minimal test case -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime
https://bugs.kde.org/show_bug.cgi?id=366035 --- Comment #14 from Frederick Eaton --- On Arch Linux, I think the only non-obvious packages needed to make the example compile are alsa-lib and libsndfile ... -- You are receiving this mail because: You are watching all bug changes.
