Description of problem: *** Fatal error: tupi is crashing with signal 11 :( Signal 11: Officially known as "segmentation fault", means that the program accessed a memory location that was not assigned. That's usually a bug in the program. Running command: "/usr/bin/sudo /usr/bin/gdb -n -nw -batch -ex where /usr/bin/tupi.bin --pid=9397" [sudo] password for user: Version-Release number of selected component (if applicable): tupi-0.2-0.09122012.2 How reproducible: a;ways Steps to Reproduce: 1.to run tupi in console and File -> New 2. to see in console Reproducible: Steps to Reproduce:
Source RPM: (none) => tupi
Created attachment 4037 [details] Disable sudo
Created attachment 4038 [details] Spec
Sollution: update tupi to release version and to apply patch for disable sudo (spec is in attachment).
Keywords: (none) => Junior_jobHardware: i586 => AllVersion: Cauldron => 3
Keywords: (none) => TriagedAssignee: bugsquad => juan.baptiste
I can't reproduce it on x86_64, which arch are you using ?
i586
Hardware: All => i586
Can't reproduce it either on i586 (on a VM installed from live KDE DVD), the application starts successfully on both arch.
No problem with start application. Problem is File -> New.
(In reply to Alex Loginov from comment #7) > No problem with start application. Problem is File -> New. Ahh I missed that part of the instructions, but still, I can't reproduce it neither in x86_64 nor i586, I can do File->New Project, then OK on the project info dialog and I get an empty canvas.
It's very strange, because this bug was reproduced by 2 people, including me.
Can you get a dgb trace ?
(In reply to Juan Luis Baptiste from comment #10) > Can you get a dgb trace ? Sorry, I mean gdb ;)
Created attachment 4084 [details] log with gdb for tupi
(In reply to Alex Loginov from comment #12) > Created attachment 4084 [details] > log with gdb for tupi That's not a gdb output, that's a strace output and it is of no use. Please install the tupi debug package and run the program through gdb.
There is no tupi debug package in repo.
(In reply to Alex Loginov from comment #14) > There is no tupi debug package in repo. Probably you don't have debug repo enabled, debug packages have their own repo.
I have no more debug info. gdb tupi GNU gdb (GDB) 7.3.50.20110722-4.mga2 (Mageia release 2) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-mageia-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... "/usr/bin/tupi": not in executable format: File format not recognized
(In reply to Alex Loginov from comment #16) > I have no more debug info. > gdb tupi > GNU gdb (GDB) 7.3.50.20110722-4.mga2 (Mageia release 2) Are you on Mageia 2 or 3 ? did you recompile tupi from mga 3 on mga 2 and are younning it there ?
Package tupi-0.2-0.09122012.2 don't work in Mageia 2 and in Mageia 3 - this bug is equivalent to. For Mageia 3 will be same: "/usr/bin/tupi": not in executable format: File format not recognized
That's something you should have mentioned since the beginning and not make QA and I loose time, manually backported packages aren't supported so this bug is invalid, tupi correctly runs on mageia 3. Closing as invalid.
Status: NEW => RESOLVEDResolution: (none) => INVALID
Tupi correctly runs on mageia 3, but File -> New don't work. log_with_gdb_for_tupi is from clean installed Mageia 3 with tupi-0.2-0.09122012.2 from official repo. I don't mark this bug MGA2TOO, because no package in official repo for Mageia 2, but this bug is in Mageia 2 and Mageia 3.
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
The log you put clearly says "Mageia 2", not 3, and I have tested tupi on at least four installations and it doesn't crash on any of them when running File->New. If it is really true that it crashes for you on mga 3 and you still aren't testing on mga 2 then there's something additionally wrong with your system. And until you don't provide a valid GDB output so we can start to pinpoint the issue we can't work on it, as I said before, the log_with_gdb attachment IS NOT a gdb output, it is a strace output and it is completely useless in this case.
In prev. comment I wrote: I tested in Mageia 2 and in Mageia 3 clean installation and bug is present. Please, write instruction how to run with gdb, because gdb don't want to run tupi. Packages gdb and tupi-debug are installed. My and your Mageia have only one difference - we uses Russian installation. Will you test tupi in Russian locale? We tested LC_ALL=C tupi and I know now - this bug is for Russian.
You need to: 1. Enable debug debug/core repository and install tupi-debuginfo. 2. Run tupi and before doing File-New, attach gdb to tupi: gdb tupi.bin <PID> Replace <PID> with the correct pid. 3. Do File->New and wait for the crash. 4. Run bt on gdb console. 5. Attach that output to this bug report. I'll try also to test in russian but I don't think I will have a different behavior.
No useful debug info. Will you reproduce bug for Russian locale? This big can be fixed only with my spec in attachment + patch for disable sudo. If use stable version tupi, then no bug, this bug is only for your unstable tupi snapshot. We tested LC_ALL=C tupi - no bug,this bug only for Russian locale.
Yes, it crashes for me too with Russian locale. I'm already working on the update.
Ok, updating the russian locale with the latest in the upstream git repo fixes the crash. So I think I will proceed by updating these two files on mga 3 and with the latest git snapshot on cauldron.
The cauldron update will take some more time because the update to ffmpeg2 broke tupi's compilation. In the mean time there's an updated version for mga 3 on core/updates_testing, which also fixes bug #10640.
@Alex Loginov: Could you test the version from core/updates_testing and report a testing procedure and your findings on bug 12119 ? This would help to speed up the validation process (and therefore help to push the update to all users). Please don't forget to mention the architecture you are testing on. Thanks in advance!
CC: (none) => wassi
tupi-0.2-0.09122012.4.mga4.i586.rpm: problem is again. ftp://ftp.mageialinux.ru/mageia2/SRPMS/tupi-0.2-3.mrc.mga2.src.rpm: no problem.
No crash with tupi-0.2-1.git04.3.mga5.i586.rpm Rémi, thank you for an update for tupi. Will you look at disable sudo?
CC: (none) => remi
I will have a look.
Hi, thanks for reporting this bug. We are sorry, but we no longer maintains this version of Mageia. Please upgrade to the latest version and reopen this bug against that version if this bug exists there. As a result we are setting this bug to CLOSED:WONTFIX Author uses sudo for Ubuntu only now. So, my patch is deprecated for current Cauldron. No crash in Caulron also. But MGA3 is EOL.
Status: REOPENED => RESOLVEDResolution: (none) => WONTFIX