[valgrind] [Bug 368873] Please add FreeBSD to the supported OS list

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368873

Yuri  changed:

   What|Removed |Added

Summary|Please add FreeBSD to   |Please add FreeBSD to the
   |supported OS list   |supported OS list

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368873] New: Please add FreeBSD to supported OS list

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368873

Bug ID: 368873
   Summary: Please add FreeBSD to supported OS list
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: FreeBSD
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: y...@tsoft.com

Hi,

valgrind currently doesn't support FreeBSD OS. As a result, version on FreeBSD
is delayed: FreeBSD still has  3.10.1 when 3.11.0 has been released almost a
year ago.

De facto, valgrind works fine on FreeBSD. So it doesn't need to be brought up
to speed, or anything like that. It just needs to be merged into and maintained
as a part of the single upstream source tree.

The current problem is that the person maintaining valgrind's FreeBSD flavor
doesn't manage to have time to sync with the upstream, so the version is
lagging in BitBucket: https://bitbucket.org/stass/valgrind-freebsd

If you add another OS, you will find out that in the long run this is also
beneficial for the project as a whole, because supporting more OSes will make
valgrind itself cleaner and more generic. I myself created many FreeBSD ports,
and I submitted hundreds of bug reports to various upstreams with bugs that
were found because FreeBSD does things a bit differently than Linux. (For
example, I found that the configure option in jq failed to turn the regex
library off, or that tor fails to create the /var/run/tor/pid file when the
enclosing directory doesn't exist. Nobody on linux ever tried these things.)

Please support FreeBSD! It is a very nice system, people who work with it never
have anything bad to say about it.


Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368861] Please make valgrind work with programs using google-perftools malloc library

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368861

Yuri  changed:

   What|Removed |Added

Summary|Please make cachegrind work |Please make valgrind work
   |with programs using |with programs using
   |google-perftools malloc |google-perftools malloc
   |library |library

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 368861] New: Please make cachegrind work with programs using google-perftools malloc library

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368861

Bug ID: 368861
   Summary: Please make cachegrind work with programs using
google-perftools malloc library
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: y...@tsoft.com

Currently valgrind fails on such programs:

==26700== Invalid write of size 8
==26700==at 0x4E45D1D: tcmalloc::Static::InitStaticVars() (in
/usr/local/lib/libtcmalloc.so.4.3.0)
==26700==by 0x4E46CA6: tcmalloc::ThreadCache::InitModule() (in
/usr/local/lib/libtcmalloc.so.4.3.0)
==26700==by 0x4E576E4: calloc (in /usr/local/lib/libtcmalloc.so.4.3.0)
==26700==by 0x9C1E139: _thr_alloc (in /lib/libthr.so.3)
==26700==by 0x9C1F292: _libpthread_init (in /lib/libthr.so.3)
==26700==by 0x9C221D1: ??? (in /lib/libthr.so.3)
==26700==by 0x9C14EA5: ??? (in /lib/libthr.so.3)
==26700==by 0x400432D: _rtld (in /libexec/ld-elf.so.1)
==26700==by 0x40024E8: ??? (in /libexec/ld-elf.so.1)
==26700==  Address 0x742b80 is not stack'd, malloc'd or (recently) free'd
==26700== 
==26700== 
==26700== Process terminating with default action of signal 11 (SIGSEGV):
dumping core


Reproducible: Always




valgrind-3.10.1

-- 
You are receiving this mail because:
You are watching all bug changes.

[extra-cmake-modules] [Bug 366110] New: Target "install/strip" is missing in Makefile when BUILD_TESTING=OFF

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366110

Bug ID: 366110
   Summary: Target "install/strip" is missing in Makefile when
BUILD_TESTING=OFF
   Product: extra-cmake-modules
   Version: 5.24.0
  Platform: FreeBSD Ports
OS: FreeBSD
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: alex.me...@kde.org
  Reporter: y...@tsoft.com
CC: ecm-bugs-n...@kde.org

FreeBSD calls "make install/strip" during the port build. It only succeeds when
BUILD_TESTING=ON.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #47 from Yuri  ---
Ah, I see. I didn't realize the pdf form-saving code was even there. This makes
the situation much better than I thought.

Thanks for clarifying this!

Somebody should just remove the code writing under ~/.kde4/share/apps/okular/

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #45 from Yuri  ---
(In reply to Carsten Gräser from comment #44)
> I gave a very detailed explanation of "in principle". just try out as
> described above.

I don't know what are you talking about. You don't make yourself clear.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #43 from Yuri  ---
(In reply to Carsten Gräser from comment #42)
> Yuri, this is not correct. Okular can in principle save the data to the pdf.
> But the interplay of this with saving to and loading from .kde/... is not
> very intuitive.

What does it mean "can in principle"? Is the code saving it to the pdf there or
not there? If it is there, can you send the link (line numbers)?

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=267350

--- Comment #41 from Yuri  ---
(In reply to Carsten Gräser from comment #40)
> Since I stumbled about this again: The following minor changes would
> increase usability of forms a lot since they make the behaviour of Okular
> more transparent.
> 
> a) Add a menu entry "save form data" that makes Okular store the data in the
> file itself.
> b) When the user tries to close a filled in form without explicitly saving
> it: Warn the user that the form data is not stores in the file (but only
> cached somewhere else) and ask if she/he want's to save now.
> c) Always give precedence to data saved in the file itself.

Carsten, the problem is that there is no code that saves to a file. There
should be two choices:
* Saving to a pdf file itself
* Saving to a separate pdf file (according to the pdf spec)
But somebody for some unknown reason implemented writing it in the proprietary
format into ~/.kde/share/apps/okular/docdata/ that makes okular unusable for
filling forms. Nobody needs the function to save forms under ~/.kde

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 359827] New: 0.9.6 4.13.3, Kubuntu packages - RAM SATURATION WHILE RENDERING HDV VIDEO

[Yuri via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359827

Bug ID: 359827
   Summary: 0.9.6 4.13.3, Kubuntu packages - RAM SATURATION WHILE
RENDERING HDV VIDEO
   Product: kdenlive
   Version: unspecified
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: critical
  Priority: NOR
 Component: Video Display & Export
  Assignee: j...@kdenlive.org
  Reporter: yuri.se...@gmail.com

Created attachment 97562
  --> https://bugs.kde.org/attachment.cgi?id=97562=edit
ram saturation after 10 seconds that the rendering has begun

Good day,

I am presently using Kdenlive 0.9.6 on UbuntuStudio 14.04.
After I start the rendering with AVCHD 1080 50i camera file (Sony HDR-CX100),
to HDV PAL 1080 50i, i can clearly see in system monitor that RAM get full
(till100%) meanwhile SWAP file is not used at all. (system ram 8gb - swap 8
gb).
Computer finally get stuck.
This problem doesn't happen if I use other other codec to render video, like
H.264 or MPEG-2 or MEPG-4.

Note about picture in attachment: if I do not stop manually the rendering
process, the memory fill until the computer get stuck. In the proposed
trend(ram is in violet colour), I have stopped manually the rendering in order
to be able to take a picture of the screen. 

Could you help me to fix this problem?
Best regards.

Yuri

-- 
You are receiving this mail because:
You are watching all bug changes.