Created attachment 7826 [details]
picture (top) of segfault shown

Created attachment 7827 [details]
picture (bottom) of segfault shown

(Curious: added 6sta1 keyword at same time as first attachment...)

Keywords: (none) => 6sta1

(This bug was for classical iso dtd 20 May 2016 )

(In reply to Dick Gevers from comment #0)
> Description of problem:
> 
> Proceed with installer to partitioning.
> 
> Choose "custom disk partioning" and "expert mode"
> 
> Mount existing swap partition, choose a few mount points for existing
> partitions and with the next one press "VIEW".
> 
> A gui comes up showing segfault (pictures to be added in next comment).
> Pressing F2 says screenshots are saved but afterwards /root/drakx is empty !

See https://bugs.mageia.org/show_bug.cgi?id=11176#c14
Until the root partition is selected + formatted, the screenshots are kept in 
  /tmp/DrakX-screenshots/
> 
> Pressing "OK" exits the installer leaving only the console to allow reboot.

So the logs are still in /tmp, too, see
https://wiki.mageia.org/en/Triage_guide#Installer-related_bugs :
> Note: before partitions are mounted for installation, the content is instead 
> in /tmp/ddebug.log So if install do not get past partitioning, this is the
> file to get. User must manually mount a media and copy that file over.

Do you mind fetching and attaching the ddebug.log?

Keywords: (none) => NEEDINFO
CC: (none) => marja11
Assignee: bugsquad => thierry.vignaud
Source RPM: classical iso dtd 20 May 2016 => drakxtools, drakx-installer-stage2

I don't mind, but I have since done a next install which succeeded.

I will try to reproduce the above later

Keywords: NEEDINFO => (none)

Created attachment 7830 [details]
report.bug from next install which segfaulted as described

Created attachment 7831 [details]
real screenshot 1 from installer

Created attachment 7832 [details]
real screenshot 2 from installer

So this happens on the second time a partition is viewed (d3e07385-02a8-41dd-9ae5-8564faf628ff,/dev/sda7) but not the first one (ab70cae6-47c7-4e20-bc01-9bb6b61786f0,/dev/sda6):

* mounting UUID=ab70cae6-47c7-4e20-bc01-9bb6b61786f0 on /tmp/inspect_tmp_dir as type ext4, options 
* ext4 already loaded
* running: mount -t ext4 UUID=ab70cae6-47c7-4e20-bc01-9bb6b61786f0 /tmp/inspect_tmp_dir -o ro
* calling umount(/tmp/inspect_tmp_dir)
* running: umount /tmp/inspect_tmp_dir
* mounting UUID=d3e07385-02a8-41dd-9ae5-8564faf628ff on /tmp/inspect_tmp_dir as type ext4, options 
* ext4 already loaded
* running: mount -t ext4 UUID=d3e07385-02a8-41dd-9ae5-8564faf628ff /tmp/inspect_tmp_dir -o ro
* segmentation fault: install crashed (maybe memory is missing?)
install::install2::sig_segv_handler() called from /usr/lib/perl5/vendor_perl/5.22.2/Gtk3.pm:566
(eval)() called from /usr/lib/perl5/vendor_perl/5.22.2/Gtk3.pm:566
Gtk3::main() called from /usr/lib/perl5/vendor_perl/5.22.2/Gtk3.pm:523
Gtk3::__ANON__() called from /usr/lib/libDrakX/mygtk3.pm:1530
mygtk3::main() called from /usr/lib/libDrakX/ugtk3.pm:859
ugtk3::main() called from /usr/lib/libDrakX/interactive/gtk.pm:41
interactive::gtk::ask_fileW() called from /usr/lib/libDrakX/interactive.pm:242
interactive::ask_directory() called from /usr/lib/libDrakX/diskdrake/interactive.pm:454
diskdrake::interactive::View() called from /usr/lib/libDrakX/diskdrake/hd_gtk.pm:151
(eval)() called from /usr/lib/libDrakX/diskdrake/hd_gtk.pm:151

I am surprised that we run main in ask_fileW

This crash seems not new and not only happening when viewing partitions but also when selecting a file in drakconnect:

http://bugs.mandrivalinux.com.narkive.com/puvgYZO6/bug-37335-drakx-net-text-new-drakconnect-crashed

We could fork the viewer in another process (like we do for help & release notes) and getting back the result through eg popen() or some other IPC mechanism or some temp file whose name is passed by an env variable

This helped us for help & the like as WebKit was prone to segfault too.

Note that you can rebuild drakx-installer-stage2 with enabling debug and replace install/stage2/mdkinst.sqfs with the one in your generated rpm

Then you can try an install with the debug stage2 and get a gdb trace

(I failed to make drakconnect to segfault after picking several time a file for eg: ndiswrapper)

Though I can make standalone diskdrake to segfault too

Created attachment 7834 [details]
GDB trace (with symbols)

Olav, this bug can be reproduced by:
- running "gdb -q --args perl /usr/libexec/drakdisk"
- selecting a partition
- clicking on "View" in right column
- browse, cancel
- reclick on "View"

As you can see in my GDB trace, the ->priv member is obviously bogus (addr @ 0x20 in first page which catch bogus accesses by segfaulting)

Status: NEW => ASSIGNED
CC: (none) => thierry.vignaud

This is still the case right?

I failed to reproduce it with diskdrake
Dick, can you still reproduce it?
Maybe latest gtk+3 updates fixed it

Sorry cant check at this time, no access to my boxes for next 10 days.

Closing for now.
Don't hesitate reopening it if needed.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED